Re: [energyinterop] Section Four proposal

[Evan Wallace <ewallace@cme.nist.gov>]

Doug Walker wrote:
> Here is a quick draft to give some ideas of a rework of section 4.  I tried to make it 
> in line with discussions today regarding ‘Party’.  I did not have the original graphics, 
> so I had to create new ones, but the main point was to put forth the idea that Actor is 
> a role that a particular entity can play.  This will potentially change for each atomic 
> service interaction. 

This is a pretty common way of understanding Actors. Actors in UML Use Cases are generally 
roles that a particular entity can play and that entity may play other roles as well.

...

> As this is a radical change, I wanted to get it out early to see if this was along the lines 
> of the group’s thoughts.

This doesn't look like a radical change to me.
The old words in the 1.0 version at lines 616-617 already implied this:
"Second, each participantOperator can in turn implement the aggregatorOperator interface..."

The introduction of the the term Party seems the primary substantive change.  Supply chain
message standards such as OAGIS also use Party to denote the entities filling various roles in 
supply chain transactions, and the EI transactions are very similar in many ways.  The use of 
Party seems a good choice here.

However, the wording describing this in the new version is unclear.  The terms 'parent' and 'child' 
are informal words used to describe a number of different kinds of hierarchical relations.  Looking
at this on my Linux system which didn't display the figures, I couldn't work out which of those
relations was meant.  The figure in 1.2 helps clarify this, but why not clarify the words as well 
by changing "This Party actor shall act as the parent for any pattern or service specific 
actors." to "Any pattern or service specific actor shall be a specialization of the Party actor."
or something similar?

With respect to figure itself, the <<extends>> stereotype should be removed.  The generalization 
connector is clearer without it as the UML <<extend>> keyword is applied only to dependency arrows 
(dashed lines with open heads) and has a different meaning (and "extends" is not a standard keyword 
or stereotype in UML [UML2.2]).

Figures 1 - 3 in the new section are excellent at illustrating the point about the roles applying to 
entities in the context of an interaction.

-Evan

Evan K. Wallace
Manufacturing Systems Integration Division
NIST



[UML2.2] OMG UML Superstructure version 2.2 
http://www.omg.org/spec/UML/2.2/Superstructure