If you�re having difficulty routing lines, you can use connectors, which simply save you having to draw a line the whole distance. When you use connectors, you must use them in pairs: one with the incoming flow, one with an outgoing flow, and both with the same label. I tend to avoid using connectors if at all possible, as they break up the visualization if the flow of control.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Originally posted by Parag Doshi:
I have some components accessing a central component (service locator) and in turn also accessing each other. Has anyone experienced such crisscross?
Originally posted by H. Hafer:
I had the same observation -- with the same components![]()
Sometimes one can avoid crisscrossing but often the results are less clear than with crisscrossing. Cohesion, e.g., should be visible by grouping the components relatively tight together. In that case, crisscrossing is ok.
However, there is only so much crisscrossing a diagram can take. In that case I split the diagrams in two or more subdiagrams by duplicating the central component.
HTH,
Harbo
Technology people seem to find this hard to understand. Components are about how customers want to relate to software. They want to be able to buy their software a piece at a time, and to be able to upgrade it just like they can upgrade their stereo. They want new pieces to work seamlessly with their old pieces, and to be able to upgrade on their own schedule, not the manufacturer's schedule. They want to be able to mix and match pieces from various manufacturers. This is a very reasonable requirement. It is just hard to satisfy.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Originally posted by Dan Drillich:
Parag,
Martin Fowler says in UML Distilled Third Edition page 124:
Regards,
Dan
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Originally posted by Parag Doshi:
Another observation I made was that my component diagram shows a flow similar to the seq diagram (controller calls dispatcher who talks to a facade which talk to ejbs etc), so, what does the component diagram give which a seq diagram doesnt?
Originally posted by Parag Doshi:
Lastly, Cade didnt show VOs in his component diagram. Why? VOs are not considered components?
Originally posted by H. Hafer:
With respect to the definition of components, they could be nearly anything, even simple classes. So why not VOs?
As far as I understand Cade's example, he simply didn't use VOs, or I'm wrong?
regards,
Harbo
Originally posted by Dhiren Joshi:
Parag,
I am slightly confused about what determines a component. The way I did I defined tiers (read in a past SCEA post of a 99 % ) .The confusion I still have is exactly what identifes a component. By breaking into tiers I was able to get ovver the criss crossing issues almost.
If u can help me identify clearly what a component is that would really help me. I have just pieced together what I think is component for a J2EE component diagram (Cade) but they dont really look like software components which is the real definition so I am kinda of confused ..
Thanks
Dhiren
Originally posted by Dhiren Joshi:
Parag,
When u break it up into tiers, u can define tiers below each other or along side.
Depedencies are between components inside the tiers and between tier packages .U cant really draw dependency between components in different tier at least not in Rose. So
moving to tiers removes the extra dependency lines u make between components from a tier to tier. Well I hope I havent confused u. This is the way I was able to figure out when other SCEAs said that they implemented in packages. Harish lately did just that. Not sure though how his implementation was.
On the question about what defines a component J2EE component seem to be in its own league in defining what a component is. I am still confused about that.
HTH
Dhiren
U cant really draw dependency between components in different tier at least not in Rose
(1)Web component: anything included in the .war component, including servlets, jsps and view helpers, filters, dispatchers, etc. Since normally we have one .war module, I take it as only one web components.
(2)EJB components: anything as a *.jar module. Since normally we have more than one *.jar modules, I take each of them as one separate components. In the case of Petstore, we have:
a)Control Component : EJB controller.
b)Signon Component
c)Customer Component
d)ShoppingCart Component
e)Inventory Component
f)Profile Component
h)Mail Component
Originally posted by Annie Zhang:
Dhiren, sorry for the confusion. I take any .war and .jar modules as components, it doesn't mean I don't take anything else as components like DAO, value list handler, fast lane reader, business delegate, service locator, view helper, dispatcher etc. From some point of view, they are all components. My point is to try to group some components together to make the diagram clear. Inside each component shows sub-components and their dependencies.
Originally posted by Parag Doshi:
I had one question though: What do we do about components which are realised in the implementation as VOs rather than domain objects (Flight, for example)? Do we still show them as components or avoid showing them at all.
I guess the more general question is, do all domain objects shown in class diagram find a place in component diagram or it depends more on implementation?
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|