What is the common way to represent this kind of diagram?

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:

@JimL. ok. sorry I edited my question and added an image. But just link cause my reputation is still small. — Raimbek Rakhimbek, Dec 13 '15 at 17:29
I see that you mention **Bonus** a lot, yet I don't see it anywhere in your diagram? You have defined some interfaces, but I don't see why? What it the purpose of the interface if it has no features to be realized? — Geert Bellekens, Dec 13 '15 at 21:14
@GeertBellekens In first time I want to make the `PaymentMethod` class and also `Payment` and so on. But when I startde to make this craft I catch a little another idea. Also, when I say `bonus`, `miles` that is the interchangable here. Cause, `customer` receives bonuses by miles. - this percent from him flown kilometers. — Raimbek Rakhimbek, Dec 14 '15 at 03:29
@JimL. so what do you think about pay method on customer ? It is good ? — Raimbek Rakhimbek, Dec 14 '15 at 16:22
@JimL. I updated the relation between customer and payments , and exchanged dependency by association with multiplicity and attribute name. And as i can see there is an aggregation relationship , and so am I need to specify this circumstence ? — Raimbek Rakhimbek, Dec 14 '15 at 17:13
Yes, I read. and it seems understand just now. I have either erase the name or attribute, cause the name will generate that attribute. What about relation between Customer and PaymentService ? — Raimbek Rakhimbek, Dec 15 '15 at 02:48
@JimL. Can u sayme that my current version of model is correct ? — Raimbek Rakhimbek, Dec 15 '15 at 03:08
@JimL. Thank you for your answer. And finally I hope that my current update is correct ? — Raimbek Rakhimbek, Dec 15 '15 at 03:22
@JimL. I did it http://stackoverflow.com/questions/34280751/what-do-you-think-about-that-diagram — Raimbek Rakhimbek, Dec 15 '15 at 03:41

score 2 · Accepted Answer · answered Dec 13 '15 at 21:59

2

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.

answered Dec 13 '15 at 21:59

Jim L.

6,177
3
21
47

Thank'sm, but you say that there is no overlap among the types of Payments. But indeed it is my requirement. It is possible to pay some part by miles and the rest by credit cardor cash. And also could you show me the relation between customer or payment. I want to use just `aggregation`, `composition`, `realization`, `dependency` and `generalization`. I mean that by methods. If my understandings good the customer must have an `list` attribute is it true ?. – Raimbek Rakhimbek Dec 14 '15 at 02:39
The overlap you need is in the collection. For example, to pay by credit card and mileage, you would pass one credit card payment and one mileage payment to the pay() operation. An instance is an instance of only one of the subclasses, but you can pass as many instances as you need to one operation call. – Jim L. Dec 14 '15 at 02:43
Ohh, thank you I will post here my drafts again later. Please, don't unsubscribe from here (if this have a plcae here) – Raimbek Rakhimbek Dec 14 '15 at 03:25
I am not sure about arrow between `PaymentService` and `Customer` FFCustomer - frequently flown customer – Raimbek Rakhimbek Dec 14 '15 at 09:29

What is the common way to represent this kind of diagram?

1 Answers1

Linked