In a software, what matters for the end users is what the system does, not what the system is. A DVD has no value for the user unless you put it into the machine.
Architecture represents what the system is, while what it does is represented by the messages between objects, which is captured via use cases. Architecture is the form, the shape of something, in this case, the objects and the mechanisms to support them.
A good definition of use case is described as the solution to a particular problem. In Jerry Weinberg's words, "problem is the definition between the current state and the desired state". It's safe to assume that state is what the system is, which can be modified by the interaction between objects.
Objects relate to the end user, its business and its components. Classes don't. Classes are a way to represent objects, the state, but they do very poorly when trying to represent what the system does. Once you hit runtime, objects morph into total obscure forms due to the endless inte