Michael Ztang

OK! Maybe I took the instructions too literally...

Is it important to provide ONE class diagram, ONE component diagram and FOUR sequence diagrams as described in assigment instructions.

In my opinion it could make sense to split diagrams in order to make them more legible.

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

I was wandering about what components in the component diagram could practically be.

The answer is, that a component is a maven module. Anybody had that idea before?

I believe that a component consists of several classes, so in my opinion a JSP is certainly not a component.

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

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?

1. I think milage has to be reduced, and the BBW application (=BookByWeb application) should trigger that in a transactional manner.
I am wondering how to interface to the mileage app? Maybe JNI? Or maybe screen scraper?

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

I think one component diagram might be enough, sine just dependencies are shown there. More interesting question is how to show different clients in the sequence diagrams without drawing the same sequences again and again...

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?