This week's book giveaway is in the Cloud forum.
We're giving away four copies of The Business Blockchain and have William Mougayar on-line!
See this thread for details.
Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Crisscrossing lines in component diagram

 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My component diagram has some lines crossing other lines. Is it normal to see such a thing in component diagram or do I need to go to the pains of making sure that none of the lines cross others?
I have some components accessing a central component (service locator) and in turn also accessing each other. Has anyone experienced such crisscross?

any help appreciated..

Parag
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Parag,

Martin Fowler says in UML Distilled Third Edition page 124:

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.


Regards,
Dan
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

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
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


Thanks Harbo. This brings up some interesting questions. Is it alright to split up the component diagram similar to seq diagram? Cade has done in his book. 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?
This is my first time with component diagrams, so wanted to know what is the intent of component diagram or I am totally missing the point?

Lastly, Cade didnt show VOs in his component diagram. Why? VOs are not considered components?


Parag
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Parag,

Martin Fowler says that a debate in the OO community is about the difference between a component and any regular class.

He also points to a good article about components:
http://www.c2.com/cgi/wiki?DoComponentsExist which says:

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.


Regards,
Dan
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Drillich:
Parag,

Martin Fowler says in UML Distilled Third Edition page 124:



Regards,
Dan


Thanks Dan. I couldnt see any example (on the net)of the connector usage as specified in your quote. Do you have any links which show it?

Thanks,
Parag
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Parag,

Please search for the word connector in http://www.agilemodeling.com/artifacts/activityDiagram.htm

Regards,
Dan
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

The flow of control as shown in a seq. diagram usually is a graph, whereas the dependencies shown in component diagrams should be trees. There could be cyclic dependencies, but that should be avoided.
Dependencies in seq. diagrams are only implicitely visible through method calls.

Originally posted by Parag Doshi:

Lastly, Cade didnt show VOs in his component diagram. Why? VOs are not considered components?

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
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


Harbo,
Cade shows VO in his sequence diagrams, hence, wanted to know why they were avoided in the component diagram.
You mentioned tree like dependencies in component diagram, could you elaborate on it? I have dependencies btw facades in my component diagram in the ejb tier, how does that translate into tree like dependencies?

I am just trying to understand the difference btw the way of showing components in component diagram vs sequence diagram.

Thanks,
Parag
[ September 23, 2004: Message edited by: Parag Doshi ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


Dhiren,
How did breaking into tiers help you get over the criss cross issue? Did you choose not to show dependencies btw components in the same tier?
The definition of components, unfortunately, differs depending on who you ask. A general definition which we all know is of a software component, which has a set of interfaces and which is pluggable,resuable, bought off the shelf etc. Cade shows JSPs as components, thats completely different from the definition I had in mind. He didnt show VOs as components (which according to me fits the definition of a reusable component. For eg. CustomerVO). So, I guess, its not entirely clear to me what is a component and what is not, in context of the component diagram.

Parag
[ September 23, 2004: Message edited by: Parag Doshi ]
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


Dhiren,
Thanks for your reply..it helps somewhat to understand the approach to component diagrams. I had a doubt though. You mentioned :

U cant really draw dependency between components in different tier at least not in Rose


If such is the case, how do you show dependency between a business delegate and session facade as both reside in different tiers (web and ejb respectively)? Is it just a shortcoming of Rose or is this dependency not shown in component diagrams?
Btw, Harish had replied to your post stating that there is dependency between components in different packages and not between packages themselves. So, if the packages are residing in different tiers, you would have lines going from one tier to another, right? Or am I missing something?

In J2EE, server side objects(jsp, servlet) are called web "components" , so maybe, Cade thinks of them as components too..

Parag

[ September 23, 2004: Message edited by: Parag Doshi ]
[ September 23, 2004: Message edited by: Parag Doshi ]
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Parag,
I guess its a short coming of Rose.
Also the way a tier is depicted in component diagram is actually in a package form. At least in Rose I wasnt able to find anything more sophisticated to show a tier. And if I put my components in it then Rose would not draw dependency links between components in separate tiers.
It would give the warning incase I tried " dependency is between packages or among components".
Now if I traverse from one package to the next then simple depedency is shown among the tiers.

Now I am also getting confused if I adopted the wrong way of depicting tiers in package..


HTH
Dhiren
 
Annie Zhang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please allow me to use Petstore as an example to show what compoments are and to see if I got it right:

(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

If I draw 8 components, inside each component shows what subsystems (components)/packages are and their dependencies. Also draw dependencies between the 8 components. In this case, the component diagram doesn't get cluttered. Too bad, I heard the rational rose doesn't allow this. I didn't try it yet.

However for the business delegate and service locator, I am not sure whether they should be put into the web component.

Or the control component should be the bridge between the web component and the ejb components. In this case, the business delegate and service locator belong here.

BTW, I wouldn't put any VO into the component diagram, since they are too detailed.

Any opinions are welcome.
 
Dhiren Joshi
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(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.


Ok web component I understand but how are you separting them into components like view helper, dispatchers. May be filters can count as components and in the same reasoning jsps and servlets.


(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


Well let me try explaining how I figured from what I get from your inputs. . Getting some idea from your reasoning .
What ever EJB jar supports in the ejb-jar.xml file, Generally define one component. So using that reasoning every model which can be defined as an EJB app can be isolated as a component.
But confusion about how service locator is also identified as a component or where does business delegate and session facade qualify to be components.
Similar confusion if value list handler or how DAO is a component. A DAO I would think it to be clubbed with the EJB components and shouldnt appear on the component diagram.

Thanks
Dhiren
 
Annie Zhang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Annie,
That was a nice take on component diagrams. It has given me a different perspective into it...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?

Thanks in advance,
Parag
[ September 26, 2004: Message edited by: Parag Doshi ]
 
Annie Zhang
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 if the VOs fit into entity beans, show them as entity beans.


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?


I guess pretty much we will have to find a place in component diagram for all domain objects in class diagram, and show how to implement them in J2EE, though some VOs which don't fit into as entity beans will have to be ignored.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic