In semplici passaggi come si può effettuare la transizione da un diagramma del caso d'uso a un diagramma di classe?
L'anno scorso ho tenuto un discorso a ICSOFT 2010 che ha affrontato quel particolare problema. La risposta non è semplice e non posso descriverlo qui per intero, ma puoi scaricare la mia presentazione qui . Scorri verso il basso fino alla diapositiva 23 "Passaggio da modelli funzionali a modelli strutturali" per questo argomento.
Il OPEN / Metis white paper contiene informazioni aggiuntive per completare la presentazione.
I passaggi di base per ottenere un modello di classe dai casi d'uso sono:
Sarò felice di estendere questa risposta con ulteriori dettagli in caso di ulteriori domande.
Ecco il mio suggerimento:
E non aspettarti che il processo "usa il diagramma del caso - > il diagramma di classe" possa essere descritto qui su SO in profondità in poche frasi. È come "Ho una foto di una macchina, per favore spiega come arrivo da lì a un progetto del motore".
La domanda è uno di "scoperta dell'oggetto"; il processo di investigazione di un requisito di sistema e l'identificazione degli "oggetti" che potrebbero implementare o essere coinvolti nel funzionamento di tale sistema. Esistono numerose tecniche per la scoperta degli oggetti, una delle più produttive e comunicative è la class-collaboration-responsibility (CRC) scheda tecnica.
Nonostante il suo nome, CRC si occupa principalmente di discovery object , non di class e forse (ORC sarebbe stato meno confuso se si lavorasse nei sistemi di comunicazione dove CRC significa qualcosa di completamente diverso), ma quest'ultimo deriva dalla scoperta del primo, e questo dovrebbe sempre essere design orientato agli oggetti non orientato in classe dopo tutto.
In ogni caso, utilizzando CRC per generare oggetti candidati, e quindi utilizzarli per "attraversare" gli scenari dei casi d'uso, puoi perfezionare il tuo insieme di oggetti candidati (scartando quelli non utilizzati e crearne di nuovi), e perfeziona le loro responsabilità e collaborazioni mentre andate. Quando si dispone di una pila di carte che soddisfano tutti gli scenari dei casi d'uso, è possibile utilizzarle per identificare classificatori e gerarchie di classi. Spesso una carta diventa una sola classe, sebbene possa aver rappresentato diversi oggetti nei passaggi, si può anche vedere che molti oggetti hanno responsabilità simili e sono di fatto una classe o sottoclassi se una super-classe comune. Tutto ciò informa le relazioni e le classi per il tuo diagramma di classe.
Le collaborazioni scoperte durante l'esercizio di CRC formano le relazioni nel diagramma di classe, la natura della collaborazione può determinare l'uso di aggregazione, composizione o altro, ma spesso è un problema di progettazione o implementazione dettagliato e potrebbe non essere ovvio o anche auspicabile a livello di progettazione del caso d'uso, che è generalmente più di un esercizio di modellamento dei requisiti o essenziale di un esercizio di modellazione dell'implementazione. Usare case-to-implementation è di solito un passo troppo grande, soprattutto se devi verificare il tuo modello con le parti interessate che possiedono forse competenze di dominio, ma non competenze nel campo dell'architettura software.
Hai solo un diagramma dei casi d'uso o hai gli scenari da seguire con gli Use-Case? Se si ha solo il diagramma dei casi d'uso, raccomanderei di creare gli scenari da seguire con gli Use-Case. Mi piacciono le frasi in inglese, ma i diagrammi di attività funzionano bene anche.
Dopo aver avuto gli scenari, il passo successivo è creare diagrammi di sequenza. Supponendo che i tuoi scenari siano stati eseguiti correttamente, le tue classi di dominio cadranno fuori dai tuoi diagrammi di sequenza in modo diretto. Puoi quindi ottimizzare le tue classi di dominio per soddisfare qualsiasi criterio tu ritenga importante nel tuo sistema.
In ogni caso, IMO, per prima cosa non ti vengono in mente le classi, nonostante alcuni metodi che suggeriscono il contrario. Risulterà solo il montaggio di pioli quadrati in fori rotondi. Lascia che le classi si identifichino e lo faranno abbastanza bene nei diagrammi di sequenza se ti prendi il tempo per imparare a fare un diagramma di sequenza correttamente e non solo per scopi manuali.
Quello che faccio è usare classi con attori, casi d'uso, ecc. come stereotipi nel mio diagramma di utilizzo, quindi trascinare e rilasciare le stesse classi nei miei diagrammi di classe. Fa il lavoro ed è piuttosto efficiente.
Questa è una domanda molto buona e interessante senza risposte precise. Esistono molte metodologie e pratiche che incoraggiano approcci simili ma diversi. Puoi trovarne uno in un'altra risposta. Altri includono la realizzazione di casi d'uso e modellazione analitica (UP), modellazione di dominio (DDD), carte CRC (RDD) e molti altri. Quello che considero simile a questi approcci è quello di esaminare i passaggi nelle descrizioni dei casi d'uso (i diagrammi dei casi d'uso non hanno molto valore in sé) e l'identificazione dei dati di input e output e la loro relazione con il dominio del problema. Da lì in poi è per lo più intuizione, credo. I casi d'uso generali non sono la fonte primaria della progettazione OO, sono importanti come specifiche di comportamento del sistema e per la gestione dei requisiti.
Leggi altre domande sui tag uml