Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: William McKenzie on February 16, 2014, 05:10:03 am
-
I'm working on a protocol that involves the exchange of messages over web sockets. The communication is bi-directional and asynchronous. There are two distinct roles (i.e. consumer and producer), and there is a subset of the messages that are allowed for each role. Essentially consumer asks for data and producer sends it. But it's asynchronous and message-based instead of RPC style.
So at each end of the communication, there will be something that looks like a bunch of calls - SendXxxx(message) when you send messages - and a bunch of events - <<signal>>OnXxxx(message) for when you receive.
Is it best model this as one interface and simply make it required of one role and provided by the other, or would it be better to make IProducer and IConsumer where each is the opposite of the other (i.e. signals become calls and vice versa).
Is there any real advantage to doing it one way or the other?
-
If you want to create code for the interfaces the IProd/ICons variant is better. If you just want to visualize the message exchange the simple message are easier to create.
q.
-
Thanks, that seems reasonable. We're actually trying to publish this as a specification, so I think probably the 2 interface definition makes more sense.
Supplemental question: I'm thinking the events are specified as methods with a stereotype of <<signal>>. Is that how you would normally do an event on an interface?
-
Stereotyping from my POV is a matter of taste. But yes, I would also choose <<signal>> in that case. Makes perfect sense.
q.