Sto facendo un diagramma del caso d'uso per un nuovo sistema. Mi chiedo quando un sistema dovrebbe essere incluso come attore nel diagramma dei casi d'uso?Quando un sistema deve essere incluso come attore nel diagramma del caso d'uso?
Grazie.
Sto facendo un diagramma del caso d'uso per un nuovo sistema. Mi chiedo quando un sistema dovrebbe essere incluso come attore nel diagramma dei casi d'uso?Quando un sistema deve essere incluso come attore nel diagramma del caso d'uso?
Grazie.
Come affermato in un'altra risposta, un attore è un sistema o un ruolo che interagisce con il sistema in fase di sviluppo. Dovresti includere un sistema come attore in un caso d'uso se è esterno al sistema che stai sviluppando e se interagisce direttamente con il sistema che stai sviluppando.
Questo è importante perché è necessario definire il limite del proprio sistema, ovvero il suo ambito e le sue interfacce. Includere un sistema come attore indica chiaramente il requisito del sistema in fase di sviluppo per fornire un'interfaccia adatta per quel sistema di attori.
È il database di il sistema è un caso d'uso come i dati di magazzino o un attore esterno a causa del fatto che riceve input o fornisce output al sistema? – commonSenseCode
Di solito, il database è considerato all'interno del limite del sistema, cioè è una parte della scatola nera che interagisce con l'attore (i) e non con l'attore stesso. Ma ci sono delle eccezioni. Supponete di progettare un nuovo sistema connesso a un database esistente che rimane così com'è, quindi potreste considerare questo come attore. Ma fallo solo se è pertinente per gli stakeholder che leggono i tuoi casi d'uso. –
Diverse persone hanno filosofie diverse su come modellare correttamente in UML (il che non è sorprendente dal momento che UML è stato standardizzato dal comitato).
Io uso gli attori per catturare ogni "cosa" (tipo di persona, tipo di sistema) che può interagire con il sistema che sto progettando e trovarli utili per creare una comprensione comune tra tutti i soggetti interessati su come il nuovo sistema sarà interagito con.
Suggerisco di creare un attore per tutto ciò che sai interagirà con il sistema e tracciare quell'attore per ogni caso d'uso che l'attore può eseguire. In questo modo, ottieni una piena comprensione di chi può fare cosa.
Il sistema non è mai un attore in un modello di caso d'uso. Devi pensare alla cosa che sta facendo scattare il sistema sotto inchiesta per portare a termine un processo. Il sistema stesso è stupido e non può attivarsi in azione. Può essere attivato solo da un utente o dal tempo. Se pensi che il sistema stia innescando l'azione, allora sarà probabilmente Time l'attore. Ad esempio, un processo viene attivato per l'esecuzione quando viene ricevuto un messaggio elettronico. Il processo è completamente automatizzato e non viene attivato da un utente che comunica al sistema che il messaggio è arrivato, quindi chi è l'attore? Non è il sistema ma il Tempo. Quello che devi immaginare è che c'è un processo per cercare l'arrivo del messaggio elettronico e questo sta guardando intervalli di tempo specifici, ad es. ogni secondo o ogni minuto o una volta al mese ecc. Quindi è il momento che attiva il processo che viene eseguito quando viene ricevuto il messaggio elettronico.
Ti sei concentrato sull'innesco e Gabriel Ščerbák si è concentrato sui confini e sulla portata. Entrambi avete indicato delle belle guide. – Alireza
Sì, sì. Le specifiche indicano chiaramente che è possibile scaricarlo da OMG e controllarlo. I sistemi esterni possono essere rappresentati come attori del diagramma del caso d'uso. E UML 2.5 definisce ufficialmente che un caso d'uso senza attori è innescato dal soggetto in cui è contenuto (un lavoro programmato per esempio). – BonanzaOne
Questo argomento potrebbe anche aiutare a chiarire quando rappresentare i sistemi come attori: [UML Use Case Diagrams: Reference] (http://msdn.microsoft.com/en-us/library/dd409432.aspx) –