non ho capito perchè cantone non ha incluso il caso umano contro umano... è una cosa che volendo possiamo aggiungere noi?

Perchè per giocare a battaglia navale in due persone devi avere due schermate diverse... il che implica che o quando uno gioca l'altro si tappa gli occhi e li riapre quando c'è la sua schermata, con il suo campo di gioco in chiaro e quello dell'altro oscurato, o un'implementazione di gioco su rete.

E noi NON vogliamo impelagarci con il gioco su rete, vero? :/

cmq a questo punto farò anch'io un unico use case diagram. Unica cosa, non so il livello di dettaglio richiesto. Nel senso, per una partita posso mettere come casi d'uso login, dispodizione flotta, svolgimento partita e refresh classifica o devo esplodere lo "svolgimento partita" con selezione casella etc..?

perchè?

PErchè nn sono diversi pure i casi d'uso???poi nn saprei...

perchè?

non ho capito perchè cantone non ha incluso il caso umano contro umano... è una cosa che volendo possiamo aggiungere noi?

non credo!!!!

non ho capito perchè cantone non ha incluso il caso umano contro umano... è una cosa che volendo possiamo aggiungere noi?

sorry sparato *****! confuso diag. delle relazioni con diagr. caso d'uso.
come non detto.

Quindi niente relazioni tra classi????Solo esplicitare quali classi servono???
E nei casi d'uso non serve esplicitarle le relazioni???
Me fuma il cervello...................

bè si,quindi siccome l'attore è un utente che interagisce con il sitema ,partirà anche un segmento che dice avvia partita cpu vs cpu,giusto?

Il diagramma è uno effettivamente, che contiene diversi casi d'uso, ognuno dei quali può essere corredato da una descrizione testuale (il professore non l'ha richiesta). Ad esempio un attore è l'utente, quindi un pupazzetto stilizzato, da questo parte un segmento con un ovale con scritto "Avvia partita utente vs CPU", questo è un caso d'uso, dallo stesso pupazzetto può partire un altro segmento ad un altro ovale con su scritto "Attiva parental control", questo è un altro caso d'uso ma il diagramma è lo stesso!!!
Correggetemi se sbaglio

Ciap

per l'dea che mi sono fatto io ,c'è da fare un diagramma che sarà costituito da due giocatori(attori) che possono essere secondo gli user needs del cantone giocatore umano computers o computer computer,ovviamente ogni giocatore dovrà sistemare le proprie navi,avere la possibilità di colpire ,e dovra avere una verifica sul colpo dato(colpito,colpito e affondato o nada) e questi saranno più o meno alcune interazioni (i nostri ovali).
ovviamente questa è la mia idea ,esprimete la vostra opinione e principalmente collabboriamo :wink:

Dall'esperienza di Ingegneria del Software vi dico:
- Stendete i requisiti d'utente (descrizione informale di quello che dovrà fare il vostro programma)
- Disegnate il CLASS DIAGRAM (mi viene il dubbio che vi chieda anche le relazioni... perché è materia d'esame!! Secondo me è sufficiente identificare le classi senza collegarle tra loro... però, io, non faccio testo)
- Disegnate il USE CASE DIAGRAM.. che, come è già stato detto, sono tutti "fumetti" che ricapitolano le azioni che gli attori fanno... (vedetevi l'esempio di D'Ambrogio!! Secondo me, può tornarvi utile: http://www.uniroma2.it/didattica/ISW1/d ... zi_OOA.pdf tralasciando, ovviamente, activity e sequence diagram. Da come potete vedere .. persino il magazzino, in un sw gestionale, è un attore...)

non so, dal corso di ingegneria del software ho capito diversamente... nel senso, uno use case diagram è una descrizione di un singolo caso d'uso dell'applicazione. Come ho detto prima, quindi, il caso d'uso di una partita e quello di un genitore che entra nel gioco solo per settare il controllo parentale vanno rappresentati con due diagrammi diversi. Penso eh.

Oltretutto nelle specifiche del compito cantone scrive "diagrammI d'uso"... poi cmq si può anche fare un diagramma GLOBALE dei casi d'uso in cui ficcare tutto. Non so, io credo che opterò per fare diversi diagrammi e poi magari metterne uno globale..

Allora:
1)Il diagramma dei casi d'uso è UNO SOLTANTO
2)un caso d'uso è un ovale,o un cerchio,che ha un nome al suo interno oppure immediatamente sotto;
3)un caso d'uso è tipicamente identificato da un verbo.questo perche i casi d'uso rappresentano in maniera astratta le funzionalità del sistema.
4)gli attori(che possono anche non esseri umani) sono entità che interagiscono con il sistema e tipicamente sono rappresentati come pupazzetti stilizzati.
5)l'interazione che gli attori manifestano con i casi d'uso è rappresentata tramite "segmenti" che collegano(in maniera direzionale?? boh) attori e casi d'uso,cioè pupazzetti e ovali.
in realtà la sintassi di questi diagrammi è piu ampia non bastano sicuramente questi 5 punti che ho messo e vi consiglio caldamente di leggere materiale a riguardo oppure un manuale su UML come sto facendo io.
sono andato su http://www.omg.org e li ho trovato le nozioni che vi ho messo in qui 5 punti e spero che abbiano fatto un po di chiarezza.
cmq se qualcuno avesse qualche spunto magari potrebbe suggerire come partire perche io anche sono piuttosto bloccato.
bella

mi sa che hai ragione te... è che penso che magari il computer, inteso come giocatore, non aprirà mai un menù a tendina, ma quando verrà il suo turno sarà cmq interessato a conoscere la griglia con le annotazioni sui precedenti colpi, o visualizzare il numero di colpi che mancano per abbattere l'avversario... utilizza in un certo senso l'applicazione.. quindi è un attore.

dove sbaglio?

secondo me invece no, perchè il computer non interagisce con l'applicazione, ma è parte dell'applicazione. Per dire, il computer non aprirà mai un menù a tendina...

In generale non mi sembra sia un utilizzatore del sfotware...

Non capisco perché state buttando in mezzo all'esercizio per domenica cose o problemi che non sono assolutamente da risolvere.
Non bisogna avere in mente codice, o scrivere relazioni o cose del genere, bisogna solo:
1)Scrivere il documento dei requisito, cioè scrivere in italiano informale quello che fa il programma, praticamente come funziona il gioco della battaglia navale.

2)Scrivere le classi del dominio del problema, cioè scrivere semplicemente le classi, senza relazioni o descrizioni, basta fare un elenco del tipo: Nave, Colpo, Giocatore ecc. ecc.

3)Fare i diagrammi dei casi d'uso, cioè dei diagrammi che mettono in evidenza le modalità con cui gli utenti interagiscono col sistema, leggete qui http://www.uniroma2.it/didattica/ISW1/d ... OOA_IV.pdf per ulteriori chiarimenti

Ciap

sì sì 2

bè però il computer al momento dell'inizializzazione diventa un giocatore, x cui prende attributi e metodi della classe giocatore proprio come per l'utente umano...



per quanto riguarda i diagrammi, sono in stallo pure io. non dovrebbe essere uno solo? poi a limite per ogni caso d'uso si spiega che succede e quali entità vengono coinvolte. [e poi ***** disegnare con word, io a malapena so fare le tabelle]

io faccio un solo diagramma,per quanto riguarda fare i diagrammi,ti c0onsiglio di farlo con power point e salvarlo come jpeg eppoi inserirlo nel documento word..
PS:Ma allora sti attori so due no?

bè però il computer al momento dell'inizializzazione diventa un giocatore, x cui prende attributi e metodi della classe giocatore proprio come per l'utente umano...



per quanto riguarda i diagrammi, sono in stallo pure io. non dovrebbe essere uno solo? poi a limite per ogni caso d'uso si spiega che succede e quali entità vengono coinvolte. [e poi che palle disegnare con word, io a malapena so fare le tabelle]

altra domanda... il computer è da considerarsi a tutti gli effetti un attore? Perchè fa cmq parte del programma, non è un'entità che interagisce col gioco...

Mi fareste gentilmente qualche esempio di caso d'uso? Perchè sinceramente a me più di un diagramma non mi viene... voglio dire, l'unico caso d'uso per un gioco è che un giocatore inizi la partita, giochi, vinca o perda e che il suo punteggio venga messo in classifica...

Al massimo un altro in cui il genitore avvia il gioco e imposta il controllo parentale.

Ma anche così sarebbero 2, non certo 10 :shock:


Delucidatemi per favore...