Dear OASIS EMIX committee.
I have some additional comments for your consideration regarding the Energy Interop Version 1.0 Candidate Standard 02 dated 27 May 2014.
There are some differences between what the narrative says and what your UML Sequence Diagrams say.
First let me say that I’m happy you’re using UML, and that you cite it as a reference document. However, since I’ve become better acquainted with UML I’ve found an epidemic of errors among us who write the standards and use UML in the process.
This email is intended to help in that area.
Line 273, Figure 1-2 has a single arrow from a Party actor to a Counter Party actor. It is a “One-way MEP where no return is expected”. A solid line with a solid arrow head is the UML symbol for a synchronous call. I believe you want to
instead use a solid line with an open arrow head here to indicate that no return is expected. This would make it an asynchronous message. In Enterprise Architect, you would simply change the message properties drop-down box from “synchronous” to “asynchronous”
and it will use the correct symbols for you.
Line 285, Figure 1-3. This figure is very confusing to me. You’ve drawn a message that issues a synchronous call from Party to CounterParty using EiRequest. The client has an activity lifeline that stays open and waits for the EiReply response
message. If your intention is to show a classic request/reply metaphor, then the response should close out the request by being represented as a synchronous response. (The dashed arrow return that you mention in line 289 that is omitted.) If instead you are
showing asynchronous messages in both directions, then (as described above) both arrows should be open arrow heads. If however you are describing a web-service-like call back mechanism as the title implies, then you have to make a decision to go for a logical
view of the activity (and use asynchronous calls back and forth) or a more detailed view of the activity (and use the solid arrow heads as shown back and forth, but answer them with acknowledgements.) I don’t think it’s a good idea to do it the way it is shown.
I’ve found that when readers are left to their own devices to imagine all of the undrawn interactions that could be present and where, the possibilities are endless.
Line 295, Figure 1-4. This is again using one arrowhead style to convey multiple meanings. I believe this violates the UML standard that you cite.
Line1520, Figure 7-1, This is a sequence diagram which I think should use a dashed line with an open arrowhead for all of the responses going to the left (Created, Reply, Cancelled.)
Figures 7-4, 7-5 7-8, 7-10, 8-1, 9-5, 9-6, 9-7, 10-1, 10-4, 10-6, 11-1, 11-4, 12-1. Again, more work is needed to use the appropriate arrows. Every arrow can’t be a synchronous call.
David Haynes
Staff Systems Scientist
Aclara
945 Hornet Dr.
Hazelwood, MO 63042 USA
+1.314.895.6452 - Direct
+1.314.249.4196 - Cell
|
|
This e-mail is intended for the addressee shown. Should you have received it in error, please delete this message and contact the sender. This e-mail and any
attachments thereto may contain information that is privileged, confidential or proprietary. Any review, dissemination or use of this transmission or its contents by persons other than the addressee or authorized employees of the intended organizations is
strictly prohibited. |
