This is a good question.
If I'm allowed to opine, I would say the language is key for modelling. The methodology you are looking for is hidden in your reading comprehension.
If the OOP is meant to be a paradigm for modelling the real world, a good question would be: What the real world is?
The real world is nothing else than our perception of this. And you guess what? Our perception is shaped by our language. In consequence, for modelling, we have to focus on the reading comprehension and to be careful with the language we use for describing the problem (the domain).
Paying attention to the language we can suppose the differents abstractions that come into play and how they collaborate with each other. I'm not saying anything new, I guess you are aware of the so famous Ubiquitous Language of Eric Evans.
To me, abstractions and responsibilities are correlated.
At this point, you might be interested in GRASP.
We can repeat the analysis of the language for each of the abstractions because each of them can be decomposed into different levels of abstractions. How many levels do we need varies from project to project, but usually, a rule of thumb is KISS.
In short, responsibilities can nest. It's OK to look inside something
with a single responsibility and find other things that have single
Regarding this process (composition/decomposition) it might interest you the top-down and bottom-up design strategies.
Take as an example a supply chain, where supplying is the top level of abstraction, while the different jobs all along the chain are lower levels of abstraction.
Top-level : Supply
Mid-level : Assembly -> Packaging -> Shipping -> Delivery
If we need improve our chain with a faster delivering process, we can address the solution changing only this responsibility without having to change the whole chain. But we can do It because we understand that delivering and shipping are different responsibilities.
When something has only one responsibility it should only have one
reason to change.
Do you need one more evidence of the importance of the language?
Oh and the class should have a name that makes the methods you find
inside no surprise at all
If you can provide your abstractions with coherent names or if the names of your abstractions can describe coherently what each of them are supposed to do, it's likely you have modelled right the responsibilities.