analisi Utilizzo caso è apparentemente semplice, ma questa domanda tradisce alcune delle complessità intrinseca.
Ogni caso d'uso deve essere significativo per gli attori coinvolti, nel senso che deve rappresentare un'interazione ben definita con il sistema. Ogni attore e caso d'uso deve anche avere un senso quando parli del sistema, anche usando il linguaggio quotidiano. Se ti trovi in difficoltà a definire attori o casi d'uso, probabilmente il contesto del sistema non è chiaro e quindi un modello di dominio potrebbe aiutarti.
Un caso d'uso deve rappresentare un'interazione ben definita, ma non necessariamente uno completo. La relazione <<include>> può essere utilizzata in situazioni in cui ha senso visualizzare casi di utilizzo dell'interazione completa e parziale allo stesso livello. Si potrebbe considerare di avere un caso d'uso buy stuff includere browse products, add product to cart e check out <<xor>> cancel, ad esempio, ognuno dei quali ha senso per il cliente.
(Sono un po 'confuso sul fatto che il vostro sistema sia destinato a transazioni fisiche o on-line, avere una cassa e stampare ricevute sembra implicare il primo, un carrello della spesa come parte dei concetti utilizzati nell'analisi il Quest'ultimo presuppone un sistema on-line.)
Nel tuo caso, tuttavia, stai parlando di attori che possono essere considerati parte del sistema stesso. Questo di solito significa che si sta tentando di definire il sistema e i suoi sottosistemi contemporaneamente, il che è comune in situazioni in cui si ha una buona idea della progettazione del sistema (eventuale) prima di iniziare l'analisi.
Quello che vuoi fare è dividere l'analisi in due livelli. Al livello superiore (di sistema), sii molto severo nel trattare il sistema nel suo insieme. Nel tuo caso, si sarebbe probabilmente bisogno di attori customer, payment partner, clerk (per un sistema fisico-transazioni), accountant (e forse administrator), e casi d'uso, come riportato sopra, più update product catalogue, audit sales log, ecc
Poi interrompi il sistema in sottosistemi e fai un'analisi separata per ciascuno di essi. Qui i sottosistemi possono essere attori nei casi d'uso degli altri.Print receipt, ad esempio, non è un caso d'uso significativo a livello di sistema perché non è di per sé un'interazione tra il sistema nel suo complesso e un attore a livello di sistema, ma è significativo come caso d'uso per il sottosistema della stampante, con la cassa come l'attore.
Non è necessario completare l'analisi a livello di sistema prima di iniziare la disfunzione del sottosistema, infatti ritengo sia meglio attivarli entrambi contemporaneamente, anche se ciò pone requisiti più elevati per l'analista/progettista essere in grado di cambiare rapidamente contesto e di essere disciplinato sul contesto in cui si lavora in un dato momento.
Quindi, dopo tutto quello che (! Uff) Penso che la risposta alle tue domande sono:
- Entrambi, fornito ogni caso d'uso ha un senso ai suoi attori come ben definito (ma non necessariamente completare) interazione con il sistema.
- Sì, ma non allo stesso livello; con un modello per il sistema e modelli separati per ogni sottosistema è possibile utilizzare i sottosistemi come attori nei casi d'uso degli altri.
Penso che il caso d'uso separato sarebbe un'idea migliore. E non ho un'idea chiara di cosa stai cercando di specificare sugli attori. –
la ragione per cui voglio che il database delle vendite, il registro delle vendite, il carrello ecc. Siano attori, è che diventa davvero facile identificare i ruoli che gli attori stanno giocando, perché posso vedere gli attori sul diagramma dei casi d'uso. non è facile da spiegare qui, ma è correlato a DCI - un nuovo paradigma: http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction –
Non sono sicuro che ciò rispetterebbe l'attore nel senso del caso d'uso . Potresti dare più spiegazioni sul perché avrebbero bisogno di essere attori? Ho rapidamente esaminato l'articolo di Wikipedia e sembra che questi ruoli siano collegati agli oggetti e la menzione di un modello di dominio fa sembrare che questi siano oggetti di dominio. Il catalogo, il database delle vendite, il registro delle vendite, il carrello, ecc. Potrebbero benissimo essere modellati come classi in un modello di dominio. In realtà questa sarebbe una pratica standard in un'applicazione di stile n-tier. –