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. Thanks, J
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.
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.
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