Class versus Component diagram

[Michael Ztang]

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?

[Darya Akbari]

Welcome to JavaRanch Michael

Originally posted by Michael Gnatz:
What is the difference between a class and a component diagram. In my opinion this is totally subject to interpretation...

Think of a class diagram of a blueprint and of a component diagram of real tangible things.

Component diagrams show also a component flow which should be followed during the detail design phase.

Regards,
Darya

[Michael Ztang]

Hello Darya,

>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?

Regards,
Michael

[Darya Akbari]

Originally posted by Michael Gnatz:
What do you mean by a blueprint??

Hi Michael,

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.

Regards,
Darya

[Michael Ztang]

Hello Darya,

> 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?

[Darya Akbari]

Hi Michael,

I think you got it . JSP, Session Beans, HTML etc. are part of a component diagram.

Regards,
Darya

[Michael Ztang]

Darya, they are single classes and so should be part of the class diagram as well.

[dinesh pande]

I see your point,..

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.

[Meghana Reddy]

Hi dinesh

Your explanation is a bit clear. Thanks much!

But do you mean to say that each component would in turn have a seperate class diagram?

Thanks

Meghana

[Michael Ztang]

A component might be considered a maven module. So it could contain classes, JSPs, EJBs and all that stuff. Anybody agree?

[Pham Huy Anh]

I think class diagram used to show the static structure of the
system being modeled. The diagram specifically shows the entities in the
system. Class is just like cell which grouped into living thing.

And component is composed (implemented) by classes and other artifacts(JSP, html, properties files...). Like part on human body: hand, head..., component provide service (functionality).

Just my global view.

[jay roy]

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 ]

[jay roy]

see the last two comments, you might find it helpful

https://coderanch.com/t/151386/java-Architect-SCEA/certification/Passed-part-II-III