[1ngienieria del softuar][pr0getto][no spam]

allora, apro sto thread sotto il permesso di hador, per parlare del progetto assegnatomi di IS, sapendo che qui dentro c'è gente che ne sa; posterò quindi i nostri progessi e se scrivo qualche cazzata vi prego di farmelo notare :sneer:
ogni post spammoso chiederò che sia cancellato(già con tutti sti diagrammi non ci sto capendo un cazzo):nod:
la parte implementativa dovrà essere un niente rispetto quella progettuale;

parte del testo del progetto in spoiler(consegnata volutamente incompleta, altri requisiti sono stati scoperti nel primo incontro con il "cliente", se ci sono domande fatele pure, sicuramente li scoprirete anche voi se seguite il progetto)

Spoiler

http://img13.imageshack.us/img13/9546/testok.png

ignorate pure la parte in LISP e LTSA, quello è il minimo :nod:

materiale da produrre per il prossimo incontro:

Spoiler

http://img710.imageshack.us/img710/2...moincontro.png

primo abbozzo del diagramma dei casi d'uso che ho creato:
http://img99.imageshack.us/img99/5817/59757326.png

la premessa è che non è una scienza esatta, comunque:

punto primo, gli use case hanno un paio di regole demenziali, una di queste è la "all day rule", cioè l'utente deve poter aver fatto quella azione tutto il giorno. Che hai fatto tutto il giorno? ho fatto il login. Login non è una azione singola. Ho creato l'ambiente... mhn... accorpa, raggruppa (c'è la cartellona in rational) le azioni comune e specificale, ad esempio crea ambiente - modifica ambiente staranno sotto una categoria di ad esempio gestione struttura ambiente o gestione delle simulazioni, inserisci/rimuovi oggetto sarà una estensione di modifica ambiente.
Il vostro sistema poi ha ottomila funzionalità automatiche, non puoi fotterne nell'use case. Ricorda che l'attore non è uguale all'utente, è uguale a qualcuno che interagisce col sistema, non devi impostare il diagramma necessariamente sull'autore.
Mancano in questo contesto tutte quelle azioni che descrivono le azioni fatte dal simulatore, che coinvolgeranno molti attori-componenti di sistema. Un esempio? Un attore/componente (dipende con che "zoom" fai il diagramma) può essere il sensore di temperatura virtuale, che rileva una temperatura virtuale su una zona. Avrai una azione che è "Simulazione Climatica", include una azione "rileva temperatura virtuale" che è collegata all'attore "sensore di temperatura virtuale". Sia chiaro che magari poi vuoi specificare che minchia siano sti attori sensore di temperatura virtuale (che di fatto sono componenti di sistema), quindi fai un altro diagramma, attore utente, e dici che l'utente può creare, gestire, configurare (es unità di misura, frequenza, cazzo ne so) i sensori di temperatura virtuale. I componenti indipendenti li puoi vedere come attori o come azioni a seconda di cosa stai cercando di far vedere col tuo diagramma.

cheffare, metti meglio le funzionalità base dell'utente e poi inizia a buttare giu le robe di sistema. Per i test funionali che vi han fatto studiare piuttosto? che quella si che mi pare una manata.

slide che ci ha presentato sui test funzionali: http://www.filefront.com/16594299/05_TestFunzionale.pdf :confused:

la all day rule c'è l'aveva detta, incorporerò un po allora...

i sensori non esistono! mi spaventa un po il fatto di aggiungere attori, mi sembrava che le cose che fa il sistema senza interagire con l'attore non dovessero rientrare in questo diagramma

ecchilo :sneer:
con use case descrivi le azioni non i componenti del sistema, se da qualche parte devi modellare la gestione del clima che dipende da una temperatura, questa deve essere calcolata da dei sensori. Che poi sia tutto virtuale via software a te non te ne frega un cazzo a questo livello dell'analisi.

viene calcolata da una formula (dipende dalla temperatura media mensile presa da una tabella, poi dall'altitudine della cella e dalla temperatura delle celle adiacenti), perchè nomini i sensori?

ah forse l'oggetto sensore serve per questa formula vero

Quote:

---

Originally Posted by Rayvaughan

slide che ci ha presentato sui test funzionali: http://www.filefront.com/16594299/05_TestFunzionale.pdf :confused:

la all day rule c'è l'aveva detta, incorporerò un po allora...

i sensori non esistono! mi spaventa un po il fatto di aggiungere attori, mi sembrava che le cose che fa il sistema senza interagire con l'attore non dovessero rientrare in questo diagramma

---

Dipende dal fatto che un programmatore debba poter o no modificare gli agenti di quella parte della simulazione. Per restare in tema, ad esempio su una simulazione simile per noi di automazione sarebbe interessante poter aggiungere svariati dipi di sensori, ad esempio sensore ideale (misurazione perfetta) o sensore reale (misurazione affetta da disturbo).

Normalmente comunque a me hanno insegnato che il primo passo è sempre quello della separazione, ovvero distinguere tra ciò che è sistema (una serie di pezzi montati in un certo modo per fare una certa cosa) e controllo (ovvero l'interfaccia che il mondo presenta agli agenti esterni). Da questo punto si può partire per creare un'architettura; nel tuo caso, per organizzare un diagramma del genere, partirei definendo gli oggetti sui quali hai a che fare, ovvero il mondo organizzato a celle. Questo mondo viene popolato di entità che possono compiere azioni, ad esempio, per scherzo, mi immagino che ci sia una divinità che crea la simulazione ambientale, ovvero un agente che modifica il clima. Dopodichè ne definisco le azioni sugli oggetti del mondo. Dopo la divinità, passo agli altri oggetti, ad esempio sensori, animali, utenti, e via dicendo. E' importante, per riassumere quindi, che tu individui un nucleo di strutture dati che vengono modificate (il mondo) ed una serie di algoritmi che le modificano compiendo azioni (clima, animali, utente, programmatore, ecc). Una volta stabilite le entità in gioco, puoi definire le interfacce con le quali i singoli agenti giocano e gli algoritmi con i queli usano queste interfacce (che sia un cristiano che sposta il mouse o un'ia per un carnivoro)

Quote:

---

Originally Posted by Rayvaughan

viene calcolata da una formula (dipende dalla temperatura media mensile presa da una tabella, poi dall'altitudine della cella e dalla temperatura delle celle adiacenti), perchè nomini i sensori?

ah forse l'oggetto sensore serve per questa formula vero lol

---

esatto non te ne frega un cazzo il fatto che sia una formula, la formula ti da una temperatura ergo è un sensore. Che poi sia una formula, un tipo col termometro o il tuo ginocchio chissenefrega, non lo devi decidere ora.

qua sia chiaro marlbo loro non devono definire l'architettura hw-sw del sistema (intesa come controllori azioni eccetera), ma il design dell'applicazione che sta un gradino sotto. Ora in italia architecture e design li traduci allo stesso modo ergo non si capisce un cazzo ma per fare un esempio client-server o SOA è una architettura, il design è la definizione, tramite diagrammi requisiti ecc, di come sono rappresentati i tuoi vari componenti (che hai identificato tramite lo studio architetturale).
Es, analisi architetturale, il mio simulatore è diviso in questi sottocomponenti che comunicano in tale maniera e complessivamente mi rifaccio ad un tipo di architettura orientata a servizi. Dopodichè tramite uml (in questo caso) vado a definire nello specifico i miei componenti specifici e l'interazione tra loro, fino al diagramma delle classi e, se necessario, di sequenza e di stato.


- poi sia chiaro che il livello di documentazione richiesto in questo progetto non è realistico dal punto di vista lavorativo e sotto certi aspetti anacronistico parlando di programmazione agile (fino ad un certo punto, un simulatore così non ti metti a farlo in xp puro comunque), ma è indubbio come non si possa prendere e programmare a testa bassa e come uml sia uno strumento potentissimo per farti ragionare, ovvio non va inteso come "ho 10 tipi di diagrammi e devo farli tutti per ogni pezzo del mio sistema".

Ma.. dove vai in uni? La struttura dell'esame è identico a quello che si fa al secondo anno in bicocca (progetto SE + una piccola parte in LTSA/LISP o LTSA/programmazione dinamica & simili) :O

Btw non sono d'accordo sull'all day rule, non c'entra tanto la durata dell'azione quanto se l'azione è di valore per l'utente. Può anche durare 5 minuti, ma se è di valore per l'utente allora va messa. Ad esempio il login non va mai messo perchè tu non è che ti metti davanti al pc per fare il login e poi te ne vai, ma ad esempio il consultare lo stato del tuo conto corrente richiede poco tempo ma è ovviamente di valore per l'utente (è un'azione per la quale vale la pena mettersi a smanettare col pc), ergo andrebbe messo.
Poi si può accorpare, ma occhio che accorpando troppo non sempre ci si becca perchè implica una crescita "esponenziale" della complessida di SSD, information flow, etc

è un secreto :nod:

agg.
http://img72.imageshack.us/img72/7198/90414643.png

mettia posto inclusioni estensioni che le hai messe a cazzo, colleg la gestione temperatura con il rilevamento

mh, ho capito il livello di dettaglio con il secondo schema, ma gestisci animale e muovi animale non sono invertiti? Cosa intendi per gestisci animale?

gestisci animale in pratica è il farlo mangiare/bere/muovere/riprodurre e ci pensa l'IA (invecchiare/morire ci penserà il sistema)

inoltre quando gli pare l'utente potrà muovere come vorrà lui l'animale

perchè collegare la gestione delle temperature con il rilevamento?

il problema è che è poco chiaro: il caso d'uso: "gestisci temperature medie mensili" vorrei farlo intendere come il fatto che qualcuno può modificare una tabella contenente le temperature medie mensili di un anno;

tabella dalla quale le formule si baseranno per calcolare la temperatura della singola cella...

per esempio: voglio emulare un ecosistema al polo sud: modifico mettendo -10 -30 -43 -13- 12 ecc
voglio emulare un ecosistema africano: la tabella conterrà 22 24 25 45 32 ecc

inclusioni ed estensioni mi confondo sempre :rain: (per non parlare poi delle cardinalità nel diagramma delle classi :rain:^2)

non so che editor usi, ma lo standard, da che ricordo, sarebbe che non ci va una freccia tra l'attore e il caso d'uso, ma una semplice linea non orientata.

usa ibm rational software architect, va bene così. Un po' di licenze fighe le abbiamo anche noi :nod:

Quote:

---

Originally Posted by Hador

usa ibm rational software architect, va bene così. Un po' di licenze fighe le abbiamo anche noi :nod:

---

Cha soldi da butta sta uni :nod:

Quote:

---

Originally Posted by Alkabar

non so che editor usi, ma lo standard, da che ricordo, sarebbe che non ci va una freccia tra l'attore e il caso d'uso, ma una semplice linea non orientata.

---

Non mi pare sia così. La freccia non orientata significa che il flusso è ambidirezionale, orientata invece se il flusso è monodirezionale