wood burning stoves
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Component/Class Diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Component/Class Diagram" Watch "Component/Class Diagram" New topic

Component/Class Diagram

Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
I've (more or less) finished my class diagram and starting on the component diagram

I've read a lot of threads on the the component diagram and what should be in it.

I think that the detail of what you put in the Component Diagram is related to the detail of what you put in the class diagram.

1 If you have a very detailed class diagram that also shows the patterns that you are using; then your component diagram can be very simple.

2 But if you have high a level class diagram that is implementation independent; then you will have to make a more detailed component diagram and show the more important desg related patterns (eg controller) in the component diagram; I am going for this option.

In both cases the sequence diagram should be most detailed and show all: jsps patterns, dao, etc, etc

Does anyone have some thoughts about this.
Stevica Vucicevic

Joined: Jan 07, 2005
Posts: 10

as I am handling my projects from the perspective of a enterprise architect I would recommend you to use the following way:

in your class diagrammt stick to the semantics of your projects and do not use explicitly functional classes that are not part of the business use case. However some functional classes should be used as they do semantics like a front controller for example, but you do not really need to mark it as a frontcontroller and when just assign a stereotype.

in you component diagramm I would group your module (e.g. JSP) as several components and mention the technology.

example: you will have searchresult.jsp displayresult.jsp in your presentation layer then assign it to a component marked Search where you mention that it is a jsp <<JSP>> according to rules of UML design.

the same way should be done with servlets

EJBs are to be mentioned separately and also all sorts of Patterns you are using except they are transparent which can happen in a framework like struts.

As far as Business logic layer is concerned your group it by package and regard it as a component.

do not forget to mention interfaces between components as mentioned in the UML speciifcation.

That is only a proposal, you can also mention every element as a component but do not forget to mention the technical background as <<xx>>
but I prefer to group them to offer again a top down view, because the component diagramme is for demonstrating purposes and also important in finding & designing interfaces.

cheers stevica
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Thanks stevica.
I followed this advise.
It is about the same as the example in Cade's guide.
and the example shown here:
(figure 3; A little unconventional UML..., but none the less)

Separate ejb's are not shown; Only the facade's are shown!

Only thing is; what if the facades contains ejb's that do not use a DAO?
Do I Show nothing then?
Do I show an Interface in between a database (Package) and the Facade and call it Persistence..??

anybody any thoughts on this?

Joined: Dec 22, 2004
Posts: 25
If you are using ejb's that do not use DAO I presume you mean entity beans? these are j2ee compoennts and therefore must be shown individually on the component digram (I presume)
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90

I don't think each entity bean needs to be shown.
In Cade's Guide and on the example:
they are not shown. I think it would be enough to show only the main facades!

In Cade's Guide for entity beans with BMP only the DAO is displayed.
My question is what to dispay for an entity bean with CMP.
I could show the bean itself.
what do you think?

Joined: Dec 22, 2004
Posts: 25

Agree with you on the first point - in the adventure example and Cade's guide only the facade's are shown. I think the business objects are all potential entity beans and he logically connects the component and class models together by showing the facade classes as the entry points into the domain model in the class diagram! This makes sense and avoids the need to explicitly describe the interaction between entity beans in the sequence diagrams since it is described by the relationships in the class diagram.

In relation to showing CMP... I think you have to show them in the component diagram to faciliatet their use in the sequence diagrams? I am going to show the main entity in a Composite and the individual entity for a Business Object as components in the component diagram. I have read here that there are 15-25 domain classes but 35-40 compoennts so this woudl follow that line

what do you think of this very long answer?
John Alden

Joined: Jan 09, 2004
Posts: 7
I was planning to show a Composite Entity Bean but then leave it at that. I struggle with where architecture ends and design begins?
I agree. Here's the link: http://aspose.com/file-tools
subject: Component/Class Diagram
It's not a secret anymore!