Obviously, to solve a problem. But, what is that problem? Is it specific or general? Is the model to represent what has to go into a database or be manipulated by code now, or to simplify a complex domain in order to understand it?
In the business space, these problems and their solutions exhibit themselves differently - one as a UML or Entity-Relationship diagrams that are or get converted to database physical models and actual structures in code - and the other as part of an enterprise architecture in which the specific models are ultimately located, given context, merged, mediated, aggregated, etc. Getting the right specific model is hard, but getting an enterprise one is almost impossible. People fight about words and representations (like is that a solid black diamond or not?) instead of semantics and meanings. They say "hey, I can't see my specific data in all this abstraction." And, they usually end up frustrated. The question is "Why?" And, my simplistic answers are "lack of education and lack of tools."
As for education, most OO teaching is about what the UML symbols mean and how to use OO design to think about specific problems (like an elevator's buttons). Are there any good books on how to model? I know that there are some on the general approach and its heuristics - like Object-Oriented Analysis and Design by Grady Booch, or Object-Oriented Design Heuristics by Arthur Riel (but this has a lot of implementation detail and less semantics than I would like to see). Let's put more focus on teaching and thinking about upper ontologies, general systems thinking/abstraction and semantic web!
On the tooling side, let's go back to our programmers vs modelers post of a few weeks ago - programmers are paid to create specific solutions, modelers are paid to get the right abstractions that can model the world. You do need both - because all the parts of the world have to fit together, in order to work together. However, the tools today do a pretty good job at the former (specific solutions) and don't do anything at all for the latter (abstracted models and upper ontologies). What should a tool do? How about hide the upper ontology - using it to make suggestions, find problems, help to lay out a specific model given the abstract one? Sure, the abstract model is just a pain when a programmer has to dig around to find where and how to subtype. The programmer gets all the complexity of the specific problem and all the complexity of the abstraction definition. Then, the baby goes out with the bath water.
More on this over the weekend ... I have some thoughts on modeling guidelines that I want to share.
Andrea