Can my class diagram handle switching between buyer and seller roles for logged-in customers?

I'm having a problem expressing two different sessions in a class diagram:

On e-commerce website we must provide one account for the customer that allows him to sign-up as a seller and buyer at the same time, if he's logged in he can switch from buyer to seller without logging out. now the problem is I already made a conception of this in this class diagram, but I'm not sure if this model makes it possible later to switch with a button! If it is right please explain the process of switching in the background, does the object seller stops being used and the object buyer starts to be used and that's all? I'm not asking about back-end details but does this model guarantee to not have chaos in database tables? Thank you

I tried to express sessions for same account in class diagram by inheriting two subclasses from class 'Entreprise' that contains customer informations.

Solution

Your design divides sessions classes into Buyer_session and Seller_session. Changing the class of an object dynamically is possible in UML. However such a change is not supported by most of the OOP programming languages. This means that in practice your design would not allow to keep the same session, but would require that you destroy one and create a new one.

Moreover, your design is flawed due to an overuse of inheritance. Your diagrams says sthat a Buyer_session and Seller_session both are some kind of Enterprise, and that an Enterprise is some kind of User. But this does not correspond to reality: a session is a session. It may involve a user account or an enterprise, but it should not inherit from them.

This is the moment to remind the principle of preferring composition over inheritance. In your case:

The first transformation to consider is that sessions would not inherit from an enterprise but be associated with an enterprise. You may then have a Session class, that would have the common features and be specialized into Buyer_session and Seller_session. The session kill and create would work, especially as the delting a session would probably require to take a decision on going operations (e.g. delete the shopping basket).
A second transformation would be to get rid of inheritance and consider the buyer/seller as specific behaviors of a session. Typically, you'd use something like the state design pattern.
A third more fundamental transformation is to differentiate the session that connects a user to the system, from the views and the transactions that may be performed during the connection. Personally I'd opt for this kind of approach, but it's a more fundamental change compared to your initial design, and the way you address the requirements.