[mikekchar]

The key to understanding classes, IMHO is that you are grouping functionality to make the code more cohesive. The style of grouping is to group the functions based on the program state where these functions make sense.

Often people go the other way around and write entity relation diagrams. They write classes to encode the data that they want to work with and put the functions that interact with the data into those classes. This actually leads to code that isn't OO (again IMHO). It actually more closely resembles modular programming. You have areas where you say, "I'm dealing with that data here". All of your instance variables are essentially global to that module. Especially when the classes become large, this becomes mostly indistinguishable from imperative code with global variables.

Instead, consider the parameters that the methods on your class use. Imagine that you had no instance variables and that you had to pass all of the parameters to your functions. Now group all of the functions that use mostly the same parameters. That's a class. The instance variables represent some state of the program and the methods work on that state. Afterwards you can make diagrams to see how these objects interact with each other, but it usually doesn't make sense to do it before hand (because otherwise you end up with bags of data and functions that act on that data as if they were global variables).

Or, more concisely: An class is not a table in a DB and you shouldn't model it the same way ;-)