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 <