L'attore è una propria classe

Io non la penso così Riconosci intuitivamente hai bisogno di un corso di Customer perché devi monitorare un Cliente, non solo le cose che fa un Cliente. Hai CustomerAccount, quindi forse è qui che si inserisce la vaghezza. Penso che questa sia la tua "Customer class".

Penso che il tuo cliente sia davvero l'attore. Dato che hai CustomerAccount, hai un oggetto Customer (che è quello che stavo citando sopra.) Ai fini di questo Sequence Diagram, non vedo come questo mostri che hai bisogno di una classe Customer oltre CustomerAccount. Una pista di controllo o un registro? Può essere. Non lo so.

Penso che Customer sia un termine improprio qui. In realtà è un CustomerSession .

Come si vede, l'attore più a sinistra acquisisce gradualmente vari token di accesso e altre risposte API e li utilizza per procedere ai passaggi successivi.

Se lo stavo progettando, userei una catena di passaggi immutabili che rappresentano ogni fase della sessione e consentirei solo di fare i prossimi passi corretti. In questo modo, il flusso di lavoro corretto era statisticamente verificabile.

class CustomerSessionInitialStep {
   CustomerSessionReservationStep makeReservation(ReservationSystem) {...}
}

class CustomerSessionAccountStep {
   CustomerSessionLocationStep enterLocation(ReservationSystem, Location) {...}
   CustomerSessionInitialStep cancelReservation(ReservationSystem) {...} 
}

// etc

Ciò che associo a Customer è identità, informazioni di contatto, ecc. Non dovrebbe cambiare nel corso di un ordine.

In alcune metodologie di progettazione, l'attore alla parte più a sinistra di un diagramma di sequenza è in realtà un'astrazione di un livello della GUI. Il nome dell'attore (cliente) è probabilmente preso da un caso d'uso, quindi possiamo risalire al requisito e comprendere il contesto. L'icona dell'attore aiuta anche a capire.

Ad esempio, in un'implementazione Java Swing della GUI, il messaggio makeAReservation() verrebbe inviato da un metodo actionPerformed() per un pulsante in una finestra di dialogo. Se l'applicazione era basata sul web, potrebbe essere una chiamata REST o un post di una pagina o di un javascript. Si potrebbe anche avere il riconoscimento vocale (come Siri) inviare il makeAReservation() una volta che riconosce la serie corretta di comandi vocali.

Ma l'aggiunta di tutti questi dettagli al diagramma lo rende più complesso. Sappiamo tutti che le GUI cambiano molto, quindi mantenetelo astratto. Pensala come la parte blu nel diagramma qui sotto:

Lasciandolo come una classe di attore si ha la flessibilità di progettare il livello di presentazione (ovvero la GUI) e si può supportare più di uno stile di presentazione.

Quindi, la risposta breve è no, il cliente non è una classe nel contesto di questo diagramma. Ciò non vuol dire, tuttavia, non si avrà una classe Customer (come una classe di dominio).

Consideriamo Cliente un corso,

Class Customer
{
  public makeAReservation();
  pubic SelectVehicle();
  pubic ConfirmReservation();
}

Prenderò il Cliente come una Classe ma non in questo contesto del diagramma di sequenza, vedendo il precedente diagramma di sequenza i metodi sopra menzionati infrangeranno l'SRP se considerassimo il Cliente come classe.

sono d'accordo con 9000's risposta