I might not be the first one raising this question...
What is the difference between a class and a component diagram. In my opinion this is totally subject to interpretation...
I could provide a component diagramm containing same elements with same stereotypes as contained in the class diagram. Just "arrows" would be different, dependencies for the component diagram and associations, aggregations, inheritance, etc. for the class diagram. All EJBs as well as pattern classes/components like BusinessDelegate or FrontController would be contained in both diagrams. Would that solution be correct?
How could that solution not be correct, since there is no hint provided by Sun?
Could it be that UML just does not have a precise definition for components...?
Maybe the following would be nice: A component contains several classes? E.g. Use Case A contains JSP_A, ViewModelA and WebActionA. Does that make sense?
>Think of a class diagram of a blueprint and of a component diagram of real tangible things.
Thanks for the reply, but I am still kind of uncertain. A class diagramm could at least be something very concrete. A one to one relationship to a java class might be possible. What do you mean by a blueprint??
A component can be touched? I think a node in a deployment diagram might be tangible, but a component is just an abstract concept... Maybe a misunderstood you?
> Component diagrams show also a component flow which should be followed during the detail design phase.
I dont understand your point at all. A component diagram contains "dependencies". They dont seem to imply any flow, at least not a temporal flow...
Sorry for giving the impression of knowing better, I dont...
What about the other candidates? How do you distinguish between class and component?
> I'm sure you know blueprints from construction buildings. They are the plans architects use to show up before they begin with the real construction work.
OK, the architects deliverable more abstract than the construction workers deliverable. The abstraction is defined clearly here: The wall as a concept of the architect is realized by the bricks of a construction worker.
Maybe the intuition should be the following: A component could be realized by several classes.
To make it more concrete (and less abstract). A jsp, a web action, a session bean, a business delegate are part of a class or component diagram? Or both?
A component can be made up of several classes. so there you go, you got one difference.
And coming to the argument of an enterprise bean such as SLSB being depicted in both class and component diagrams, the key difference would be a SLSB in a class diagram might show the individual classes that the SLSB depends on, but the SLSB in a component diagram would not worry about other individual classes it depends on, instead it only shows dependencies across other components.
Take the example of a component named "PaymentProcessor", so much detail is abstracted in this component, however how this PaymentProcessor will be build and what this whole component is comprised of, may be depicted by a class diagram.
It may sound I am saying the obvious thing, but the above explanation should satisfy the original poster's question.
you could think of a 'component' as a individual java module which interact with another java module. For example: an 'Order system' interacting with a 'customer repository system'.
here 'Order system' and 'customer repository system' are two components. A simple example would be : when the client(jsp) places an order, the 'Order system' is invoked which calls the 'customer repository system' . The 'customer repository system' would check if the customer is in database.
So 'Order system' and 'customer repository system' internally have classes which interact with each other. Example the 'Order system' could have Business Delegate class interacting with Ejb and 'customer repository system' could have the DAO class interacting with the database.
any comments appreciated.. [ May 14, 2007: Message edited by: jay roy ]