What is the common way to represent this kind of d

Question

I need to represent the payment of a customer to buy a flight ticket in an airport. The system of airport has a bonus system.

So customer can make payment for ticket by a bonus or by another payment system or together. But I don't know how to represent it all together.

I wanna make the interface that called PaymentMethod and make this hierarchy : ByPaymentSystem(Interface), ByBonuse(Class), ByMix(Class that dependet from ByPaymentSystem)

Payment system will also have many realizations f.e. : webmoney, mastercard and so on.

And also I wanna make a PaymentService class that will have method pay that will take a parameter method:PaymentMethod and also take an specific information about the kind of payment.

I am not sure about ByMix class, and my spirit wanna avoid this class.

What do u think about it ?

Please don't break down my reputation but just comment your opinion. I will review them and than make decision about destiny of this topic. Also I prepeare imagine all my thoughts about subj in UML class diagram if that will be necessary.

This is the my draft of a part of my diagram

I wanna make something like that but i don't know how to deal further. How to represent payment by mixed case: by bonuses and by credit cash.

UPD: This project is the site of an avia-company. The company have bonuse miles system. That means the frequently flying customers can receive some free kilometeres bonuses by that they can pay some part of a flight. Of course they can make payment by credit card or even combine that methods. - there I have stock. How to represent that combination ?

I need to represent the class diagram that will satisfy the desires above.

UPD:

Answer 1

You should start with a model of the problem domain. I would expect something like the following:

This diagram states that:

• A Customer offers one or more Payments to a Payment Service
• A Payment Service accepts one or more Payments offered by a Customer
• Each Payment has an amount
• A Payment must be a Mileage Payment, Cash Payment, or Credit Card Payment
• There is no overlap among the types of Payments

To then answer your question in terms of the solution domain, I would have your pay() method accept a collection of payments. You don't need subordinate interfaces for each kind of Payment, only various class implementations. I would use polymorphic operations to debit (if that's the right word), roll back if anything fails, and commit when all the debits succeed.