Using recursive relationships or “pig ears ” in a class diagram

Teacher noticed that there is a ring in this part, and advised to use "pig's ear"
I couldn't find much information or examples regarding this.
Here is the only thing that is written everywhere
>reflexive relationships, which are sometimes called recursive relationships or "pig ears" (because the image of such a relationship in the drawing looks like a pig's ear — if you use a little imagination!). Note that this relationship is always optional; otherwise, it would be by definition an infinite hierarchy. We'll look at this rule later when we start studying invalid and unrealizable data structures.

Perhaps someone can explain with examples how to use "pig's ear" and how to change my diagram for it.

Your teacher was certainly mislead by the graphic. Even with some imagination, I have trouble to find a really justified reflexive class her (+1 for anybody answering with a plausible case which is not mentioned here).

First advice: try group the generalizations to the same class using a shared target. Here the shared target would be User,

Second advice: then show move all the shared properties to the shared target. In you diagram, one would have the impression that pupil and parent both have names, but that staff and admin have not.

Third advice: never start to add properties that implement associations in your diagram. At least, not before your model is bullet-proof. In your case for example, parent.pupilId suggests that there is only one pupil for a parent, whereas the list indicates several. This is confusing.

Fourth advice: play mentally with your model to see if it matches the case of real life. For example:

• A parent can have several children in the school (ok)
• A child can have several parents with an account (not ok: you use composition with a black diamond, which means that every child belongs to only one parent)
• A child can have an account, but parents don't have internet and have no account (not ok: composition also requires that there is a parent account for the child account to exist).
• A teacher (staff) has own children in school (not ok: because because staff has no children. Workaround: the teacher has one account as staff, and one account as parent)(tip: if you have already implemented your system, and do not want to change, you can feature this flaw by telling your customer that it's to increase security and avoid that the teacher changes the grades of its own children by abusing authorizations )
• The same for admin (but uif you featured the previous flaw instead of fixing it, you are now screwed...)
• An admin is staff (not ok, unless two accounts are used).
• A parent may also be a pupil (not ok) (you don't believe me? My kids went to the music school of my town. I found it nice, so I myself became a pupil, desperately trying to learn guitar).

Fifth advice: when in doubt, prefer composition over inheritance. But also use composition only if you are absolutely certain that composed object (on the other side of the diamond) are exclusively owned and cannot exist without the composite (and here, we are not speaking of children and parents, but children accounts adn parent accounts).

After applying all these principle, you'd probably get a model closer to this one:

Cross-check: you can answer yes on all the cases above.

Now, if you want to please your teacher, instead of a one-to-many relation from user to role, you can do a one to 0..1 composition, and add a reflexive composition between one role and 0..1 other roles, creating a chain of roles.

Last advice(for today): don't use this "pig ear" term. It's ambiguous (+1 for having done your research), it's not commonly used (ok, I already heard "ear", and "mikey-mouse ear"), it gives a bias by encouraging to look for a second ear, and last not least, it creates an emotional bias (I see it negative, but that impression might be cultural).