How to show ConcreteCommand on message in Seq Diag

[Paul Lotz]

We have successfully implemented an interface using the Command Pattern.  I had a sequence diagram in which I showed the commands on messages in order to express the interactions, but I created the message names and parameters manually (and they were notional for that reason).

I am now trying to update the sequence diagram so that the messages rigorously link to the proper model elements, but I am not sure how to do this (if it is possible, which regrettably it might not be).

So I have something like this:
Command class is abstract and any number of ConcreteCommand classes, each of which has its own unique attributes (if any).
I have a CommandSignal with an attribute command:Command.
I have two interfaces: ICommander, ICommandee, and on my sequence diagram ICommander sends a message to ICommandee.

Now I can define the message as type CommandSignal but then the message parameter is command, which isn't very useful on the sequence diagram.

I can instead define an operation on ICommandee that I call command(), but this doesn't have the parameter I want.

Or I can define a series of operations that I call concreteCommandA(), concreteCommandB(), etc., but if I define parameters of type CommandA, CommandB, etc., this doesn't help me with the parameter specification on the message either.

What I want, of course, is to have the message parameters from the proper ConcreteCommand class.

Is there a way to do this?

As I write, I suppose I could (haven't tried this yet) define the parameters on concreteOperationA to match those for ConcreteCommandA, but then if I change an attribute on ConcreteCommandA, then, unfortunately, concreteOperationA will not automatically follow suit.

Is there a better way?

Thanks!

Paul

[Geert Bellekens]

Paul,

I'm having trouble following your explanation.
You might want to show us a diagram to explain the situation.
http://A while ago I documented the command pattern at http://themodelfactory.org/Pattern:Command, but I don't think I ran into the issues you're having.

Geert

[Paul Lotz]

Geert,

Thanks for the link.  For some reason I am unable to see any but the top image on that page in my browser.

Another way of describing the issue I see is this: I send all the commands via a single signal topic, so thinking that way I can make this signal of type Command (using your diagram).  Unfortunately, then, if I link a message to the signal the message has the parameters (if any) associated with Command, and not CommandA.

Upon reflection, I have decided one approach is to ignore the signal aspect of this, and just model operations on the Receiver.  Each operation corresponds to a concrete command (e.g., CommandA).  Then I can link the message to the operation via the Call option.  Unfortunately, since CommandA is a class I have to create the operations separately (a Class is not a Signal nor an Operation), which makes the model more difficult to maintain.

An approach that might work would be to model all the concrete commands (CommandA, CommandB, etc.) not as classes but as signals.  Then the messages could take their attributes from the particular signal type.  This might actually be the cleanest way.  I'm not sure if this has any real drawbacks (except that in our case I am hesitant to change what we already have released).

[Geert Bellekens]

Paul,

I guess you are browsing with Internet Explorer (v7)?
In that case try another browser, that should solve the issue with the diagrams.
IE7 has a really poor support for some of the features used by the diagrams.

Geert

[Paul Lotz]

Geert,

You are correct.  I was using IE.  I just tried with Mozilla and I can see the images with that browser.

Paul

[Paul Lotz]

Let me pose the question another way.

I have modeled all the various commands as classes in a Class diagram.

Now I want to create a sequence diagram showing the intereactions between systems.  I want to show messages, where each message is a particular one of the commands (i.e., a signal that invokes an operation--more or less--on the receiver).  How can I best model the messages, since the Command classes are themselves neither operations on the receiver nor signals (semantically, that is; they are logically signals)?

Note that I can create corresponding operations on the receiver, or I can create signals, but in either case I am duplicating the information already contained in the command classes--and this makes it harder to maintain the model.  I think I have to choose one of these solutions--make "duplicate" operations or "duplicate" signals, and that's OK, but it's not ideal and I'm wondering if there is a better approach.