I'd advise you to take another look at the functional specification and identify nouns, because a lot of those will become class names in your program.
If there is no functional specification, create one. I don't like writing documentation either, but trust me, it will prevent so many headaches. If that seems a bit overwhelming right now, just have a relaxed read of this series of articles, it will explain why and how and has a template to get started. Ultimately it's just explaining to other people what the app does, so not that much different from what you did when you wrote this question.
One of the sentences in this question will probably end up in that specification as it is:
Members of this association have different roles and each role has specific characteristics.
The nouns here are "Members", "association", "roles" and "characteristics". Your specific issue concerned the combination of members and roles. What's important to note here is that "role" is a noun. Long story short, a
Role would make a good class. Even if a
Role ends up containing nothing more than that name-string, it still makes sense because it allows you to say in code "There is a
Role and I give it the name "Instructor". There is another
Role and I give it the name "Vehicle Manager".
You can then connect these roles to members in different ways, the simplest among them being a
Role just having a list of
Members. If a
Member wants to manage vehicles, you check if they have an entry in the vehicle manager
Role. How exactly you solve that will depend heavily on the rest of your app though.
Some more advice
I'd advise you to avoid inheritance. It's overhyped by universities and tutorials. Every time you are tempted to use inheritance, think if you can't use composition instead. This wasn't really the issue in this case, but you will ultimately run into the problems described in the link user bitsoflogic commented under your question.
As an example, I'd like to cite your given structure,
Member. Does a non-member person even make sense in your application? If a person is a user who has not logged in yet, then you have no idea what their name, surname, and date of birth are.
Now, it's understandable if you want the personal information name, surname, and date of birth separate from other more business-oriented data. You will just run into less problems if you use composition instead: Just make every
Member have an instance of a new class
PersonalInformation which contains name, surname, and date of birth.