OOA & D: ricerca di sistemi e attori quando sono coinvolti più processi

In un certo senso, questo tipo di analisi è soggettivo, ma diventa utile in base al fatto se aiuta veramente le persone a capire un sistema e ne migliora il design, elimina i problemi e / o lo valorizza al di là delle sue attuali capacità.

Quando un'azienda ha sia un sistema di fatturazione che un sistema di buste paga, è chiaro dove tracciare la linea nei SuD (Sistemi in progettazione). Guardando a questo articolo, mi sembra che si stia tentando di scindere quello che è essenzialmente un sistema con un unico obiettivo in più SuD semplicemente per il gusto dell'esercizio. La mia reazione istintiva è che ciò che abbiamo qui è un sistema di gestione degli allarmi che interagisce con componenti di sistema sia interni che di proprietà del fornitore. Da questo punto di vista, come scritto, c'è un solo obiettivo e un solo SU: "Il sistema di gestione degli allarmi". Il problema del collegamento di più marche è l'integrazione con i fornitori esterni, non con la progettazione di un sistema.

Un altro modo di considerarlo è che l'integrazione con i prodotti del fornitore è abbastanza complessa da richiedere un sotto-progetto in sé e per sé. In questo scenario, è possibile che si stia esaminando un "Sistema di comunicazione fornitore" e un "Sistema di gestione allarmi". Quale è giusto? Ciò potrebbe richiedere una revisione dei diagrammi architettonici per il sistema esistente per effettuare questa chiamata.

Si noti che un altro analista potrebbe dividerlo in modo diverso. Queste sono solo le mie migliori interpretazioni di ciò che hai scritto finora.

Gli attori hanno un obiettivo specifico all'interno di un sistema. In un sistema di database, potrei avere un software che esegue query sul DB utilizzando un accesso specifico per eseguire alcune funzioni automatizzate senza che l'utente inizi l'azione. In tal caso, avrebbe senso che il software iniziasse le query a essere elencato come attore con l'obiettivo della sua funzione specifica di essere lo "scopo dell'attore".

In questo caso, l'app mobile e il server Web si sentono come componenti di sistema su cui agiscono gli amministratori, il personale addetto al monitoraggio della sicurezza e gli utenti finali del servizio software. Gli amministratori gestiscono gli account utente e, come detto, eseguono una sorta di gestione degli allarmi. Gli utenti finali ottengono abilitare / disabilitare gli allarmi per tutti i marchi controllati dal sistema di over-arc. Il personale addetto al monitoraggio della sicurezza dovrebbe essere analizzato un po 'più da vicino. Questo è un ruolo o diversi? Cosa devono fare e quali informazioni hanno bisogno di farlo? Queste domande potrebbero consentire una migliore elaborazione degli attori all'interno dei centri di monitoraggio.

Per gli attori secondari, questo articolo potrebbe aiutare (vedere la definizione modificata dopo l'originale in alto):

link

Secondo il mio modo di pensare, i server TCP e gli allarmi potrebbero adattarsi alla precedente definizione di attori secondari, ma pensare agli umani effettivi dai marchi che stai cercando di controllare potrebbe essere necessario per modificare o migliorare il sistema potrebbe illuminare meglio potenziali ostacoli alle decisioni future sul design.

Spero che lo trovi utile.