[UML] Creazione di Class Diagram

[Neptune]

Salve a tutti,
mi ritrovo per l'università a dover fare un progetto, nella progettazione ovviamente mi tocca fare un class diagram (poi il tutto sarà sviluppato in c# con la compact framework perchè girerà su windows mobile).

Ora ho mille dubbi su come devo fare questo class diagram. Ovvero, quanti e quali classi fare? come procedere alla creazione delle classi iniziando da una traccia che simula "il volere di un utonto medio" ovvero i requisiti funzionali?

ma anche, se uso la classe "text" del framework dite che andrà anche quella nel class diagram? o ci metto solo le classi che ho realizzato io?!

Sono in alto mare e il professore è restio a dare aiuti dicendo che ce la dobbiamo cavare da soli.

Se avete qualche how-to, dispensa o shamano che sia sono tutto orecchie

[MisterBean]

Allora, sostanzialmente un diagramma UML ti guida in quella che sarà l'implementazione pratica delle specifiche del tuo progetto. Rappresenta l'organizzazione delle classi che fanno parte del tuo progetto, con dipendenze, ereditarietà, aggregazioni e tutte le relazioni possibili che puoi avere tra queste classi. Se usi una classe del framework per implementare determinate funzionalità non la devi inserire nell'UML. Il class diagram infatti serve solamente a far capire come è strutturato il tuo progetto, senza specificare come i metodi sono implementati.
Riguardo a come procedere devi vedere tu anche in base a ciò che il tuo programma deve fare. Inizia a "pensare in termini di oggetti" a una soluzione per i problemi che devi risolvere, e l'UML verrà di conseguenza

[deleted_29]

Originariamente inviato da Neptune
...Ovvero, quanti e quali classi fare? come procedere alla creazione delle classi iniziando da una traccia che simula "il volere di un utonto medio" ovvero i requisiti funzionali?...

Cominciamo col dire che UML non è altro che un (semi) standard per pittogrammi.

Ossia disegnini di livello di "intelligenza", così a occhio, della V elementare (anche se vengono spacciati come il Santo Graal, bisogna avere un pochino di esperienza per vederli in prospettiva, sono la versione diciamo newage dei diagrammi di flusso).

OK, detto questo, così a occhio non hai la minima idea di come si progetti un software, e questo ci può stare, non è che si "nasca imparati".

Però, prima di porti il problema di come fare dei (sostanzialmente inutili) disegnini, inizia a porti il problema di aver ben compreso cosa sia un oggetto, e una classe, e come si modelli (o meglio "come si può", ci sono 10000 approcci diversi, spesso anche migliori di questo) la realtà per passare gli esamini

[Neptune]

la teoria sulla programmazione ad oggetti la ho, e' che sulla progettazione che non so da dove iniziare,anche perche' cosi di primo acchitto non saprei se fare una o piu classi specifiche, se esagero con la frammentazione delle classi o se le speializzo poco e mi perdo tutta l'invarianza al cambiamentoin un colpo solo. Insomma mi servirebbe un peontuario che mi facco da linea guida visto che e' la prima volta..

[MisterBean]

In generale i passi da seguire sono:
1) Analizzo il problema che mi è dato, e preparo una lista di requisiti che l'applicazione deve soddisfare (senza pensare a come implementarli!).
2) Comincio a creare la struttura del progetto e a pensare alle varie classi che possono servire per implementare le funzionalità.
3) Scrivo codice.
4) Testo il corretto funzionamento del tutto.
I punti 2 e 3 sono soggettivi, si affidano in gran parte all'esperienza e alle capacità di ognuno nel problem-solving.
Esistono però delle best practices chè è opportuno seguire, come concentrarsi sull'estendibilità del codice (in sostanza, cercare di sfruttare al massimo ereditarietà e polimorfismo) e sulla sua manutenibilità (quindi prestare attenzione alla modularità).
Se ti è chiaro ciò che devi realizzare, inizia a preoccuparti di come strutturarlo in maniera "furba", in modo che sia facilmente estendibile. La stesura di un class diagram allora verrà naturale, ma è solo la conclusione di un percorso di progettazione, non l'inizio.

[Neptune]

Originariamente inviato da MisterBean
In generale i passi da seguire sono:
1) Analizzo il problema che mi è dato, e preparo una lista di requisiti che l'applicazione deve soddisfare (senza pensare a come implementarli!).
2) Comincio a creare la struttura del progetto e a pensare alle varie classi che possono servire per implementare le funzionalità.
3) Scrivo codice.
4) Testo il corretto funzionamento del tutto.
I punti 2 e 3 sono soggettivi, si affidano in gran parte all'esperienza e alle capacità di ognuno nel problem-solving.
Esistono però delle best practices chè è opportuno seguire, come concentrarsi sull'estendibilità del codice (in sostanza, cercare di sfruttare al massimo ereditarietà e polimorfismo) e sulla sua manutenibilità (quindi prestare attenzione alla modularità).
Se ti è chiaro ciò che devi realizzare, inizia a preoccuparti di come strutturarlo in maniera "furba", in modo che sia facilmente estendibile. La stesura di un class diagram allora verrà naturale, ma è solo la conclusione di un percorso di progettazione, non l'inizio.

Ho già i requisiti funzionali belli e scritti nella traccia. Mi sono scritto, in maniera spero corretta, i casi d'uso.

Ora questo strutturare in maniera più riutilizzabile possibile mi sfugge.

In poche parole il progetto è un programma per cellullare, che legge da un file di testo in input (che dovrebbe simulare dei sensori wirless che trasmettono dati, ma non avendo questi sensori facciamo finta che leggiamo ogni tot di tempo dal file di testo), e:

Visualizza a schermo i valori letti utilizzando un opportuna formattazione;
Da delle cromatizzazioni dello schermo se i valori letti vanno oltr una soglia e riproduce anche un suono di allarme;

Memorizza su un file di journaling questi dati e, all'utente che utilizza il cellullare ogni giorno gli permette di visualizzare solo le ultime 100 stringhe del file di journaling, ad un autorità di controllo (un'altra tipologia di utente) permtte di visualizzare l'intero storico.

Il progetto prevede anche due successive reimplementazioni ovviamente atte ad incasinarti nel caso hai progettato male la prima.

A questo punto che faccio? non sapendo che mi aspetta per il futuro cerco di fare classi più specifiche possibili così alla peggio non mi tocca stravolgere il codice?

Mi tocca farlo in c# con compact framework per i cellullari, dove posso trovare una guida rapidissima? mi serve anche grossomodo capire che tipo di ereditarieta supporta, perchè queste cose le ho studiate in linea generale e poi le ho applicate in java, ma per il c# proprio non saprei.

E' anche vero che il progetto si deve slegare dal codice, però se so già che lo devo sviluppare in c# e metti caso che il linguaggio non supporta l'ereditarietà multipla, magari evito di fare certe cose nella progettazione.

[MisterBean]

In sostanza si tratta di strutturare il tuo progetto in moduli ben definiti, ognuno dei quali implementa una determinata funzionalità della tua applicazione ed è "a sè stante", nel senso che potrebbe essere preso e portato dentro un'altra applicazione per fornire la medesima funzionalità. Scrivere codice riutilizzabile significa sviluppare vari moduli che vengono poi fatti interagire. Questo implica ovviamente che ogni modulo deve fare esclusivamente ciò che gli compete (ad esempio, il modulo di interfacciamento con il file - sensori, il modulo di gestione delle diverse utenze devono occuparsi solamente di quello). L'interazione tra questi e con l'utente è realizzata dal controllore e dall'interfaccia del programma.
Inscatolare le varie funzionalità in blocchi componibili rende il programma estendibile e riutilizzabile, infatti se un giorno volessi aggiungere una funzionalità, lo potresti fare tranquillamente con un nuovo modulo. Stessa cosa se volessi modificare l'implementazione di una funzionalità esistente, ti basterebbe modificare il codice all'interno di quel modulo e non altrove.

Per la guida purtroppo non ne conosco, non ho mai programmato in C#. Spero di essere stato comprensibile sul resto.

[Neptune]

Originariamente inviato da MisterBean
In sostanza si tratta di strutturare il tuo progetto in moduli ben definiti, ognuno dei quali implementa una determinata funzionalità della tua applicazione ed è "a sè stante", nel senso che potrebbe essere preso e portato dentro un'altra applicazione per fornire la medesima funzionalità. Scrivere codice riutilizzabile significa sviluppare vari moduli che vengono poi fatti interagire. Questo implica ovviamente che ogni modulo deve fare esclusivamente ciò che gli compete (ad esempio, il modulo di interfacciamento con il file - sensori, il modulo di gestione delle diverse utenze devono occuparsi solamente di quello). L'interazione tra questi e con l'utente è realizzata dal controllore e dall'interfaccia del programma.
Inscatolare le varie funzionalità in blocchi componibili rende il programma estendibile e riutilizzabile, infatti se un giorno volessi aggiungere una funzionalità, lo potresti fare tranquillamente con un nuovo modulo. Stessa cosa se volessi modificare l'implementazione di una funzionalità esistente, ti basterebbe modificare il codice all'interno di quel modulo e non altrove.

Per la guida purtroppo non ne conosco, non ho mai programmato in C#. Spero di essere stato comprensibile sul resto.

Ok mi sfugge però il ruolo del controllore, cioè facciamo finta che ho come funzionalità/classi:

Lettura da file;
visualizzazione/cromatizzazione schermo;
mostra storico degli ultimi 100 elementi;
emetti suono;

Ora devo prevedere anche una classe di controllo che mi unisca il tutto? Non sarà una specie di main del programma a caricarmi tutta l'interfaccia e poi a seconda dell'utente dove clicca mi si lancia una funzionalità anzichè un'altra?

Oddio in java ogni classe aveva un suo main, quindi li magari avrebbe avuto senso una classe di controllo, in c# mi pare che il main sia unico, quindi può essere lui

[MisterBean]

Il ruolo del controllore è semplicemente quello di chiamare le funzionalità che l'utente richiede al momento in cui vengono richieste... È ciò che fa "dialogare" l'interfaccia grafica con il modello sottostante, per maggiori dettagli guarda qui.
Dipende anche da come si realizzano le interfacce grafiche in C#, però in linea di massima servono dei moduli e un qualcosa che permetta di ricevere l'input dall'utente e presentare i dati richiesti.
Solitamente il "main" si occupa della creazione iniziale dell'applicazione, in seguito l'interfaccia si mette in ascolto degli input dati dall'utente, e chiama le funzioni del controllore per la modifica/gestione dei dati. Il controllore si occupa quindi di chiamare i moduli che gestiscono le funzionalità richieste dall'utente.

[Neptune]

Originariamente inviato da MisterBean
Il ruolo del controllore è semplicemente quello di chiamare le funzionalità che l'utente richiede al momento in cui vengono richieste... È ciò che fa "dialogare" l'interfaccia grafica con il modello sottostante, per maggiori dettagli guarda qui.
Dipende anche da come si realizzano le interfacce grafiche in C#, però in linea di massima servono dei moduli e un qualcosa che permetta di ricevere l'input dall'utente e presentare i dati richiesti.
Solitamente il "main" si occupa della creazione iniziale dell'applicazione, in seguito l'interfaccia si mette in ascolto degli input dati dall'utente, e chiama le funzioni del controllore per la modifica/gestione dei dati. Il controllore si occupa quindi di chiamare i moduli che gestiscono le funzionalità richieste dall'utente.

Mha che io mi ricordi a spanne almeno del vb.net, che dovrebbe essere simile, per quel poco che ho fatto, quando cliccavi tipo su un bottone innescavi una sorta di "classe-evento", ma non è che c'era un controllore. Il main lanciava tutta l'interfaccia grafica e poi a seconda di dove cliccavi passavi al codice del singolo bottone/menu a tendina o altro.