Thanks for using a more realistic name
One of the points I was trying to address in my first reply is that when designing for an OO system, you have probably "got the wrong end of the stick" if you start with thinking about data or ER models.
If you start by thinking about behaviour, then chosing which concepts to deal with as objects can become a much simpler decision. If a concept has no behaviour or responsibilities, it's probably not a very suitable candidate to be an object.
As an aside, have you considered
Test Driven Design (TDD)? I've found that it can really help cut through this sort of "design fog" and lead to really elegant and effective designs which you might never have thought of when trying to do design in the absence of code.
In Test Driven Design, you design your system in lots of tiny little steps, with every step you experiment a little, learn more about the system and the requirements, and base each design decision on what you have learned so far.
Choose a tiny piece of desired functionality and write an "executable test case" for it. I write my tests for my
Java software in Java using
JUnit, for example. The key is that all your tests can be quickly and simply run by the machine. You are going to need to run your tests hundreds or even thousands of times before your design is complete, so the simpler and quicker they are, the better.
Writing your test code is the first step in designing your solution - it makes you think in real, practical, terms about how other objects and processes will invoke your new functionality. If you've ever met software with cumbersome. overcomplicated APIs, you'll appreciate this step!
Then, before you have written any "real" code, run all the tests you have written so far. Everything should pass except the test you have just written. This is the second part of the design process. It's an experiment to discover whether any code actually needs to be written. If your new test passes, you dont need to write any new code for this feature, it already works! I've seen far too may bloated designs full of un-needed code, which could have been greatly simplified by making use of someting as easy as this.
If this initial "reality check" fails, it's time to design another experiment. If you've been good, and chosen a really tiny bit of new functionality, you should be able to quickly come up with a simple implementation. It's probably not the
best implementation, but that's not important at the moment. This is more of a "prototype" to see if you understand the requirement enough to implement
any solution at all. Tweak this until all your tests pass.
So, all your tests pass. Now, the real design work for your new feature can begin. You've done your experiments and discovered that (a) you can make a workable API for the new functionality, (b) some code actually needs to be written and (c) you understand the problem enough to make a "prototype" which works.
Study your "prototype" code in the context of the rest of the system. Refactor and improve it (in tiny steps, remember), making sure to rerun your whole test suite after every little change. Don't be afraid to change other parts of the system as you go, if you see a chance to simplify something. You have already written a complete "regression" test suite for all the features you have implemented so far. Your tests will tell you straight away if you break anything.
When you can't think of anything else which can be improved, your design for this small step of functionality is complete. As a bonus, so is the coding and testing!
Make sure your code is checked in to some sort of source-code repository, and move on to consider the next tiny piece of functionality.
Skilled practitioners of TDD can run through this whole cycle many times a day, and achieve astonishing productivity of robust, well-designed, fully-tested code. It's an incredible feeling when you begin to realise that the code you are designing is going somewhere better, simpler, and more elegant than you originally thought of.
The "trick" of all this is to consider program design like science, and base your designs on observation and experiment rather than just pulling guesses out of thin air. This post turned out longer than I expected. I hope it helped!