|more useful options|
I know it sounds a tad naive, but the 'nouns and verbs' approach *can* work quite well with OO.
Ask yourself "who or what does *things* within this system?", then ask "what is it that they do?".
Also, on a personal note; I tended to find when I started using OO as a methodology, I worried a little too much about when and where to use inheritance.
My tip is; you don't need to use inheritance as much as you might think, the component-based approach can often be better (i.e. the "HAS-a-whatever" rather than "IS-a-whatever".
To take an example (from, I think, some of the perl OO docs); you might think that you should have a virtual base class Employee, which you would subclass to, say, DeveloperEmployee and ManagerEmployee and ProjectManagerEmployee because all three are (for sure) employees of one kind or another.
But consider for a moment the notion that an Employee (as a concrete class, i.e. one having instances) could have an *attribute* of role, which would the be DeveloperRole or ManagerRole or ProjectManagerRole; you than have the flexibility of variable behaviour from one Employee to another, without the rigidity enforced by an inheritance hierarchy.
Employees can change roles without losing their identity, which more closely models the real(tm) world.
On a more general note, I would say; ease into it gently. One of the *many* joys of Perl (and for me, the principal one), is that there's no "proper", enforced way to do things.
Enjoy the freedom from having to do OO all-at-once as you'd have to do with (say) Java, and just dip a toe. You don't have to intimidate yourself with doing the whole OO-design thing right from the off, you can just experiment and become comfortable with one concept at a time.
OO *CAN* be fun, if you take it one step at a time.
Forgive the rambling post, I'm having an evangelical moment.