I don’t think so. You recognize intuitively you need a Customer class because you need to track a Customer, not just things a Customer does. You have CustomerAccount, so perhaps that is where vagueness sets in. I think this is your “Customer class.”

I think your Customer is indeed the actor. Since you have CustomerAccount, you have a Customer object (which is what I was mentioning above.) For the purpose of this Sequence Diagram, I do not see how it shows you need a Customer class beyond CustomerAccount. An audit trail or log? Maybe. I don’t know.

I think Customer is a misnomer here. Actually it’s a CustomerSession.

As we see, the leftmost actor gradually acquires various access tokens and other API responses, and uses them to proceed to next steps.

If I were designing it, I’d use a chain of immutable steps that represent each step of the session, and would only allow to make the next correct steps. This way, the correct workflow was statically verifiable.

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

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

// etc

What I associate with a Customer is identity, contact information, etc. It should not change in the course of making an order.

In some design methodologies, the Actor at the left-most part of a sequence diagram is actually an abstraction of a GUI layer. The Actor name (Customer) is likely taken from a Use Case, so we can trace to the requirement and understand the context. The actor icon also helps understand.

For example, in a Java Swing implementation of the GUI, the makeAReservation() message would be sent from within an actionPerformed() method for a button in a dialog. If the application was web-based, it’s maybe a REST call or a post from a page or javascript. You could even have voice recognition (like Siri) send the makeAReservation() once it recognizes the proper series of voice commands.

But adding all these details to the diagram make it more complex. We all know that GUIs change a lot, so keep it abstract. Think of it as the blue part in the diagram below:

Leaving it as an Actor class gives you flexibility to design the presentation layer (aka GUI), and you can support more than one style of presentation.

So, the short answer is no, Customer is not a class in the context of this diagram. That is not to say, however, you won’t have a Customer class (as a domain class).

Lets consider Customer a class,

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

I would take Customer as a Class but not in this sequence diagram context, by seeing the above sequence diagram the methods mentioned above will break the SRP if we would consider Customer as class.

i agree with 9000’s answer