Tata Indica, Maruti Van, Mahindra Xylo might either be the possible values of a Property. Or they might be Classes. Which is right? That depends on the domain of the system.
For the Property case, you would have a Type property that might takes those values. If we know those are the only possible value, then the type of that Property might be an Enum.
Tata Indica, Maruti Van, Mahindra Xylo appear - I say by intuition - to be vehicle models. This tells us that, they are unlikely to change during the life-time of the vehicle, and this probably isn't an exhaustive list. Thus, I'd advice against using an Enum. If you use Enum, adding a new model in the future would be a problem. Under the same argument I'd advice against using a Class.
However, given the context - this appears to be a homework, I also say by intuition - there probably is a teacher expecting you to use Classes. Go use classes, get a good grade.
Grade aside, here is something for you to think about: Making classes for different colors of cars would be a bad idea. You can create a class diagram where
Yellow Car and so on, inherit from
Car. However, representing a paint job operation in the system would mean to change the Class of the object. Let alone the problem of making a Class for each possible color… And then somebody wants a car with two colors. Thankfully, car model does not change like that (well, not usually).
And, of course, if
Tata Indica, Maruti Van, Mahindra Xylo must have different properties, then you would have a better argument for making them classes. Yet, that depends on exactly what is your system trying to solve. Are the differences between
Tata Indica, Maruti Van, Mahindra Xylo part of your domain or not? If they aren't, you do not need classes for them. If they are, then, perhaps.
A system needs a boundary.