Il database in un diagramma di sequenza deve essere rappresentato come attore o limite?

1

Sto progettando un sistema costituito da un'applicazione web e un database. Io uso gli stereotipi <<Entity>> - <<Control>> - <<Boundary>> nel mio diagramma UML.

Nel seguente diagramma di sequenza, ho già un'interazione con un sistema nel cloud. Voglio ora mostrare anche il database interno (sullo stesso server). Devo rappresentarlo come attore o come <<Entity>> ? E se ho bisogno di ottenere informazioni dal database devo inserire un oggetto di confine tra il database e l'entità (come cloudBoundary tra Student e il sistema cloud)?

    
posta khalid 02.12.2017 - 10:39
fonte

1 risposta

0

Versione breve:

Il database gioca tecnicamente lo stesso ruolo del tuo sistema cloud, anche se è locale sul tuo server. Quindi potresti rappresentarlo con un attore (se davvero devi scegliere qualcosa).

Poiché il database è esterno al tuo sistema, devi ovviamente avere alcuni oggetti limite (es. gateway ) per consentire agli altri oggetti di interagire con esso.

Spiegazioni

L'approccio Entity-Control-Boundary è strettamente correlato usare la modellazione del caso:

  • L'idea del loro inventore, Ivar Jacobson, era quella di derivare in modo sistematico le classi richieste in un sistema per implementare i casi d'uso identificati.
  • La filosofia è quindi che le classi di confine rappresentano il collegamento tra attori e casi d'uso, che le classi di controllo sono mappate su alcuni casi d'uso e che le classi di entità rappresentano gli oggetti di dominio.

In un modello di caso d'uso, gli attori sono umani o sistemi esterni che interagiscono con il sistema allo scopo di raggiungere un caso d'uso (vale a dire un'intenzione di un attore o un requisito aziendale). Per questo motivo, i database di solito non fanno parte dei diagrammi dei casi d'uso.

I database vengono visualizzati se si scava al di sotto della superficie del caso d'uso. Il database non dovrebbe essere di per sé un'entità, né un controllo, né un limite. Anche se dal punto di vista del caso di utilizzo il database potrebbe essere compreso come parte del sistema preso in considerazione (perché non è un sistema esterno coinvolto nelle interazioni aziendali), tecnicamente, rimane una componente indipendente, esterna al sistema che stanno sviluppando.

Lo stereotipo <<Entity>> è abbastanza comune da essere standardizzato in UML, totalmente in linea con la comprensione della BCE:

<<Entity>>: A persistent information component representing a business concept.

Chiaramente, il tuo database non è un'entità in base a questa comprensione. Anche se dovessi sviluppare il tuo database da zero come parte del sistema.

<<Boundary>> e <<Control>> sono stereotipi non standard . Ma se è necessario accedere al database esterno, è necessario un oggetto limite che funga da connettore / gateway.

Se dovessi sviluppare un database da zero, come parte del tuo sistema, allora il database stesso sarebbe composto da un sacco di <<Control>> oggetti che gestiranno il flusso di informazioni e interazioni in relazione con gli altri controlli, entità e limiti (in particolare gli oggetti stream che rappresenterebbero il limite del file system).

    
risposta data 02.12.2017 - 16:01
fonte

Leggi altre domande sui tag