UML class diagrams are typically used to model classes and interfaces.
Component diagrams show components, the dependencies between them, and the interfaces which they implement and/or require. Typically implemented interfaces are modelled as lollipops on these types of diagrams, although there is nothing stopping you (other than CASE tool lack of flexibility) from modeling an interface box with an implements or requires dependency with a component.
Originally posted by JJ Captain: Is correct show classes and interfaces in component diagram?
Formally this is correct, but in praxi?
Component diagrams are especially usefull when going to assemble an allredy designed and implemented system or subsystem or component for deployment, therefore showing - compilation dependencies - execution / call dependencies - abstraction dependencies (x.class refine x.java) - any other team defined dependencies between two or more components via their interfaces.
But how to define the inner structure of one plugable / replaceable component? Regardless of - using one component diagram per component and showing its classes or - showing several components along with their classes, in both cases each component will be defined and will be reusable in a deployment diagram later.
If the system is trivial enough, you could mix up inter- and intra-component dependencies within one huge diagram. But for complex systems I prefer to - define the intra-component dependencies in one component diagram per component and showing its classes and - define the inter-component dependencies in one or more separate component diagrams showing only interfaces and dependencies, no classes.