connectionpath between artifacts

[Andrew Chen]

hi all,
i'm currently trying to draw a deployment diagram.in grammar, is it correct 1) to put artifacts into a node and 2)directly connect two artifacts from two diferrent nodes, with a communication path.


thanks

[qwerty]

There's nothing wrong with that. In the end: if you feel the diagram expresses your thoughts it's correct by default.

q.

[KP]

+1 for qwerty's pragmatic approach.

However according to UML, "A CommunicationPath is an Association between two DeploymentTargets, through which they may exchange Signals and Messages." In your example, the Nodes are the DeploymentTargets, not the Artifacts.

[Andrew Chen]

1.Thanks all.
2.hi KP,
if i just connect the two nodes by the communicationpath, is there any graceful way to indicate that artifact1 actually communicate with artifact3 inside Node2?
thanks

[Paolo F Cantoni]

Hi Andrew,

Just for interest's sake, what are the artifacts?

In general, artifacts don't communicate, they just are...

Since:
An Artifact is any physical piece of information used or produced by a system, represented in a Deployment diagram.

Paolo

[Andrew Chen]

Hi Paolo,
the artifacts are Program1.exe, Program2.exe, Program3.exe and Program4.exe. They listen to/send messages to some ports, say, Program1.exe sends messages to port number 1000 of node2, and  Program3.exe inside node2 keeps listening that port number for incoming messages.

[KP]

Program3.exe (the Artifact) doesn't listen for incoming messages, it doesn't do anything; it's a binary file, just data on your disk. It's the runtime environment (the Node) that executes your program and does all the work. Which is why you attach the CommunicationPath connectors to the Nodes.

If you want to say that Program1 and Program2 communicate, you need a Component diagram, and then you can have a Manifestation connector between your "Program1" component and "Program1.exe" artifact to say that the latter is a physical manifestation of the former.

[Andrew Chen]

hi KP,
great thanks for correcting me. i'm still a newbie. any recommanded reading can make me familiar with UML?
thanks

[qwerty]

UML is a large land. You should probably start in regions of greater interest. What helped me was a video tutorial by Dough Rosenberg from ICONIX which I bought many years ago. Maybe it's still for sale somewhere here on Sparx site.

q.