Quali sono gli attori in un caso di utilizzo del server di back-end?

When generating the use cases for that server who would be considered as the actor?

La tua domanda definisce il server di backend come Sistema in Discussione (SuD). Qualunque cosa interagisca con SuD è un attore, quindi la risposta diretta è "Sistema (front-end)".

Ma attenzione alle insidie più comuni:

1. È essenziale scrivere scenari a livello di obiettivo utente prima e solo da loro spiegarsi al livello inferiore. "Front-end o utente" è in qualche modo un falso dilemma, ognuno di essi può essere
2. Considerare la situazione in cui la convalida di oggi viene eseguita nel front-end JS, domani nel back-end e il giorno successivo gestito dai vincoli DB. Tali modifiche annullerebbero immediatamente molti casi d'uso se il back-end è un attore. Ecco perché la maggior parte delle volte dovresti essere molto cauto nell'introdurre componenti di sistema come attori . Invece scrivi scenari di sottofunzione in cui il sistema come unico attore fa tutte le complicate convalide e operazioni passo dopo passo e livello per livello.
3. Gli scenari con back-end come attore sono garantiti che non vengano letti dagli utenti . Quindi dovresti descrivere tutto il comportamento due volte, in quegli scenari per la gente dell'IT e da qualche altra parte per il business. Il che porta tutti i tipi di problemi come lavoro aggiuntivo e riconciliazione.

Al centro di un diagramma dei casi d'uso dovresti pensarci in termini del Soggetto che vuoi descrivere. Il Oggetto è definito come:

A subject is a classifier (including subsystem, component, or even class) representing a business, software system, physical system or device under analysis, design, or consideration, having some behavior, and to which a set of use cases applies.

Fonte: link

L'Oggetto mostra varie Azioni eseguite dal Soggetto. L'Oggetto è interagito con Attori . Attore è definito come:

A role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject.

Fonte: link

Il server del database suona come l'Oggetto importante in riproduzione, quindi non ci sono regole che dicono che dovresti usare un componente software Front End o l'utente finale come attore nel tuo diagramma. Dipende completamente da come pensi che il caso d'uso debba essere comunicato.

Detto questo, spetta a te decidere se questo Use Case avrebbe o meno un valore reale o se è troppo granulare. Chiaramente il Database è interessante come soggetto in quanto è un componente software appropriato, tuttavia non tutte le interazioni fatte da un componente hanno un attore interessante che potresti voler pubblicizzare.

È possibile utilizzare i diagrammi Use Case per descrizioni di livello alto o basso, sebbene a volte trovo che i diagrammi Use Case siano più interessanti ad alto livello con Business Actors e le comunicazioni tra sistemi possono essere meglio descritte con qualcosa come un Diagramma componenti.