Hi Jeff
"Classes" and "objects" are 2 different things. The meaning of the words are not related to whether they are used in the context of analysis modelling or design modelling.
This is from the UML spec:
A class is the descriptor for a set of objects with similar structure, behavior, and relationships.
An object represents a particular instance of a class. It has identity and attribute values.
IMO it doesn't really make sense to have an inheritance relationship between objects, because objects are what they are.
I will give you a simple example:
We could have a class called "Human" in our analysis model, which contains attributes such as e.g. birth date, height, weight, name, etc. Note that these attribute do not have values in the class. I.e. the class "Human" cannot have a specific birth date or height.
Then we make 2 classes called "Man" and "Woman". They both have inheritance relationships to "Human", because they are specializations of "Human". Each of the 2 classes could then have attributes that relate specifically to men or women respectively.
Then we instantiate "Man", i.e. we create an object of class "Man". We set the "name" attribute of that object to "Jeff". The object with name="Jeff" does not have an inheritance relationship to the class "human", but its classifier ("Man") does.
When you are doing your domain analysis modelling, you'll want to describe concepts of your problem domain in general (=classes). At that point you are not interested in specific, individual things (=objects).
Objects are suitable for modelling something specific, such as a specific person opening a specific file and printing it on a specific printer. Some people like to start with a specific case like this, and then use it as a guide to identify classifiers afterwards. E.g., maybe you know about "Jeff" wanting to open "account.xls" and printing it on "HP Laserjet". From that model of instances you can then say to yourself: "Oh, I think I need the classes "Accountant", "Spreadsheet file" and "Printer".
Personally I mostly use objects when I model interactions, i.e. in sequence diagrams and collaboration diagrams. Messages are passed between objects, not between classes, because classes are not things that actually exist. A class describes common characteristics of objects that actually exist.
I'll tell you briefly what I do:
My Analysis Model contains classes that represent real-world concepts from the problem domain. Often those classes also appear as nouns in my use cases.
When I find it necessary, I create some sample interactions between instances (objects) of those classes. The interaction diagrams help me clarify the problem in my mind.
My Design Model contains classes that will exist in the software implementation. Often these classes are taken from or at least inspired by classes in the Analysis Model. I create interactions between instances (objects) of the software classes to establish what relations are needed. Or I create a sequence diagram from a use case in order to establish what classes are needed. Still, the interaction take place between instances (objects), not classes.
This turned out quite a bit longer than I planned, and it may be too basic for you, but it just seemed that you had classes and objects a bit confused. I hope this could help you.
Mikkel
