collaboration diagram problem

[andro]

Hi
I have a problem which could be described as follows:
there's a customer coming to an office. He reports to the head clerk and requires a service of some sort. The head clerk tells him to wait a minute, goes to a place where clerks sit waiting to be assigned a customer, picks one of them and tells him to serve the guy in a blue coat. Having been provided the customer's identifiaction, the assigned clerk goes to the customer and serves.
I have drawn a diagram as follows:

My problem is how to denote on the diagram that the head clerk, being able to identify the customer (that is to tell him from other customers), passes the customer's id (the "blue coat" info) to the assigned clerk. I know there are message parameters that I could use but I would like just to DRAW it on the diagram.
Is there a way to do it?

[sargasso]

using parameters on the message

1.1 allocateClerk (CustID)

or

using return value and parameters on the message
1.1 Customer.Allocated=allocateClerk(CustID)

or

1.1 Clerk.Busy=Clerk.Allocate(CustID)


or even
1.1 Cutomer.AllocatedClerk=Clerk.Allocate(CustID)



hth
Bruce

[andro]

Thanks.
Yes, it helps - well, sort of. I hoped there was a way to put it graphically. Now, thinking of it again, I understand that to depict passing customer's id to Head Clerk and from there to Clerk requires mixing this collaboration diagram with a class diagram which would show the dependencies.  And doing this would make the diagram messy. Do I get it right?
andro

[sargasso]

Andro,

Yes, I think that you could do it that way. In fact I see no problem with including the class on the collab diagram if it adds clarity.  I have, as a matter of fact, one interaction in a system that we had been "discussing" for several days trying to decide where a particular object should be created. (A trivial and pedantic exercise perhaps, but the issue was fairly germaine to the design approaches (and architecture principals) that we were proposing.  The minute we plonked the class element into the diagram the real issue crystalised - it was a mismatch in assumptions made by the group as to what the attributes of the class were going to be.  As soon as this was resolved the class element was removed again and the "published" interactions rewritten to remove the ambiguity.

In general though, I find no problem with putting the paramters on the messages and the way EA lets me display the paramaters as either caller attribute names or callee types gives great flexibility.

B

[andro]

You mean, like this?

I know it's not exactly what I originally described, but that's what I had in mind. Customer except for the very moment when he requests service, communicates with the system exclusively through his "CustomerPort" - an object that both identifies him and serves as a communication medium. I think a good example is when Customer calls a helpdesk, somebody picks up the receiver, and then says to another person: "answer this phone".
I wonder, if sending a message from Clerk, which is a part of the communication diagram, to CustomerPort, which in turn belongs to the class diagram, is legal.
andro

[sargasso]

Andro,
I have sent you a diagram directly as I cant post to a website from here. If you would stick it up here I will discuss it.
B

[andro]

Here's your diagram, Bruce.

I have a feeling I know what the point is but will be glad to hear your comment.
Thank you very much.
Regards,
Andro.

[sargasso]

I mainly wanted to show how we use the classes on the communication diagram to add the clarity and evolve the design to the next level.

The diagram (as it stands) is not "pure" UML but it does show that the "important" element is the CustomerPort object and (I think) show the true order of events so we can create the lifelines later.

Customer is the initiator of the first sequence.  It is the only object that knows its identity at this time.  It can certainly generate the creation of a new Call:CustomerPort object and supply its own Identity to it.  Call can then get the attention of the HeadClerk object as in "Hey, I'm a newly created call!"
HeadClerk can look around the room decide that ClerkX isn't working hard enough and tell Call to Allocate itself to ClerkX.
HeadClerk is now out of the way (in terms of Call) and can go back doing whatever else.
Call alerts ClerkX that he is to handle it (TakeCall)  and ClerkX must respond.... etc

Now the diagram is slightly wrong here..  I have shown supply service as a call on Customer by Clerk.  In reality it should be more properly a call on Call by Clerk, but I left it this way to make things clearer at this time and would fix it later.

What we see by adding the classes is that the object knowing information about the call and controlling the execution is the Call.  Its temporary existence matches the real-world situation, it can provide the services that are need by the system (as I understand them) and none of the other (more persistent) classes need concern themselves with that "call" information or methods.

Bruce

[andro]

Thanks, Bruce.
I understand the diagram and agree it shows what I described. Nevertheless it seems that there's indeed no way to put passing information along messages graphically - we must use messages' parameters, right? Remember? I was wondering if there was a way to draw some associacions between, say, HeadClerk and Call to depict that Clerk's reference is passed with the Allocate message.
Best regards,
andro.

[sargasso]

Andro,

First let me correct the d**n errors on my diagram.  The parameter for CustomerPort.Allocate should be "clerk" not ClerkID, similarly clerk.TakeCall(CustID) should be clerk.TakeCall(Cust).  i.e. I want to pass the entire object.  
Also, I should have named the Clerk object something a bit more discriminant like "Fred:clerk" and Customer something like "Mary:Cust".

Now, the messages become
1 new(Customer.ID)
1.1 RequestService()
1.2 AllocateClerk(Fred)
1.2.1 TakeCall(Mary)

Is this what you mean by

to depict that Clerk's reference is passed with the Allocate message

?

I must admit that I cannot see how adding a link between a message and a passed object would add clarity to the diagram. :-/
Perhaps you could mock up what you are trying to do in a diagram tool and let us look at it.

B

[andro]

Bruce,
The answer to your question is "yes, that's what I meant".
I have no option left but to accept what you said. I'm that new to UML. I really can't tell what is more and what is less clear. I thought it would be more clear if all the information was put graphically.
The problem I wanted to model is so simple that in fact it doesn't require any UML diagram. It was just for the sake of practice. Well, I wanted to model the simplest client-server cooperation over a TCP/IP socket. You know, the client opens a connection, a listening socket on the server catches it, assigns it a communication process which from this moment carries on the conversation with the client.
Regards,
andro.

[thomaskilian]

Hi Andro,
sometimes it is easier to write things down than to draw pictures (despite the proverb: a picture tells more than a 1000 words). In my opinion UML leads many people to lay too much emphasis on graphics (which indeed looks great most times). However, you don't have to forget plain text documentation. Only a good balance between both will lead you to a good result.

Cheers, Thomas

[andro]

Right. This cheers me up. Is this why most people don't place their diagrams in this forum?  
By the way, I think it would be great to have a forum of a special kind here - a forum where people would post descriptions of simple problems, to be modelled in UML, together with initial EA files. Others would comment on them and place refined EA files of their own, and so on.
What do you think?
I would enclose here a model of this idea, if I new UML.
Regards,
andro

[thomaskilian]

Hi Andro,
things are already on their way (I hope). Have a look here: http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=general;action=display;num=1077009102

Cheers, Thomas