That problem, figuring what the classes should be, is the classic one
confronted by programmers who are moving to the object-oriented paradigm.
I've only seen one book on OOPS that used real examples.
To conform to the paradigm, which is defined from a Smalltalk point of
view, most OOPS programmers attempt to design a pure hierarchy, making
everything subordinate to something else with a root class at the top. It
is my observation that this approach leads to unnatural relationships. An
example: because project has a start date and an employee has a hire date,
department and employee classes are derived from the date class. It doesn't
even look right. Better to include the date class as members of the
department and employee class. Don't build a hierarchy–build a bunch of
classes and derive only where it makes sense.
My new book is a tutorial on the language not on OOPS. I use C++ as an
improved C and use classes to extend C with new data types.