Search code examples
oopumlsystem-design

Design a bank account and membership UML diagram (OO design)

I'm designing a back account membership system with UML diagram.

My idea is that create a class userAccount and 2 subclasses savingAccount and currentAccount that inherits userAccounts

With membership, I have created a membership interface Membership and 3 classes implemented, Gold, Silver, Bronze.

So I wanted different membership to have different withdraw limit and transfer limit for both accounts, but only the interestRateCalculation() will be applied into the savingAccount class.

I have implemented the UML diagram like the way in the picture.the UML Diagram

However, I feel like this is not the right way of implementing this. Since the accounts didn't inherit the membership classes, so the methods in the accounts classes shouldn't be able to retrieve those methods in the membership classes. But if not implemented with this way, I cannot find a better way to implement it.

I would like to know what is the more accurate way to implement the diagram. Much appreciated.

Solution

  • All I see in the membership classes seems independent of any account, if this is true :

    • There are only 1 instance of each sub class in all the system, so a total of 3 and each is a singleton.

    • The fact IMembership aggregates userAccount has no sense, it does not have to know the accounts

    • Probably an account is associated to one and only one of the three singleton, allowing an account to know the limits and how to compute the interest. In that case you have a directional association from userAccount to IMembership

    It is abnormal the attributes withdrawLimit and transfertLimit are present in the four membership classes, they must be present only in IMembership whose must be an abstract class rather than an interface

    For me userAccount must be an abstract class because you cannot have an account whose is not one of the two sub classes.

    The operations getWithdrawLimit and getTransfertLimit only depend on the membership so they are defined on userAccount rather than on the sub classes, of course these operation call the corresponding one on the associated membership instance.

    enter image description here

    (I do not defined the constructor to save time)

    Yes in case of a currentAccount the computation of the interest is useless, but if you want to avoid that you have to double the memberships classes, the directed association to a membership is not on userAccount but each sub class, and the operations getWithdrawLimit and getTransfertLimit are abstract in userAccount. This is more complicated and I don't think it's worth the effort